Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

not all trigger_events are working #52

Open
dkuettel opened this issue Aug 16, 2022 · 5 comments
Open

not all trigger_events are working #52

dkuettel opened this issue Aug 16, 2022 · 5 comments

Comments

@dkuettel
Copy link

Hi,

trigger_events = { "InsertLeave", "TextChanged", "CursorHold", "CursorHoldI", "FocusLost" } reacts only for the first two events, as in the default settings. It used to work before the rewrite, except for FocusLost but I think that's on my side.

Cheers, Daniel.

@dkuettel
Copy link
Author

Just as a side-note: I think I've seen someone else complaining in an issue about the rewrite. I understand that things dont just work right away without bugs.
But as someone that checks out your plugin using a git submodule, it's quite hard to follow what's happening when you keep on force-pushing on master. Not everyone might agree, but in general I think it's not a good idea to rewrite git history that other people have already checked out.

@chetbaby
Copy link

I had {"BufLeave", "BufWipeout", "VimLeave" } and it doesn't respect any of those. It just keeps saving on InsertLeave which makes my setup unusable because the autoformatting kicks in and using u to undo is useless because it finds itself in a loop.

@ehaynes99
Copy link

I can all but guarantee that this is due to the use of api.nvim_get_current_buf().

When you create an autocmd, the callback function receives an object parameter, and when the event is based on a buffer action, that object will contain a buf option, which is the buffer number. You should always use this instead of looking up the buffer, as it can change. With the debouncing, it's all but guaranteed to save the wrong buffer when it eventually fires.

@lucasrabiec
Copy link

lucasrabiec commented Mar 4, 2023

I had {"BufLeave", "BufWipeout", "VimLeave" } and it doesn't respect any of those. It just keeps saving on InsertLeave which makes my setup unusable because the autoformatting kicks in and using u to undo is useless because it finds itself in a loop.

I also had this issue with BufLeave, etc. in LazyVim (with auto-save.nvim), even if I didn't have InsertLeave and TextChanged in my config it always saves file while I exit INSERT mode.
I removed the plugin and added auto-command:

-- /lua/config/autocmds.lua
local function augroup(name)
  return vim.api.nvim_create_augroup("lazyvim_" .. name, { clear = true })
end

vim.api.nvim_create_autocmd({ "BufLeave", "WinLeave", "FocusLost" }, {
  callback = function()
    local curbuf = vim.api.nvim_get_current_buf()
    if not vim.api.nvim_buf_get_option(curbuf, "modified") or vim.fn.getbufvar(curbuf, "&modifiable") == 0 then
      return
    end

    vim.cmd([[silent! update]])
  end,
  pattern = "*",
  group = augroup("autosave"),
})

@primeapple
Copy link

Check out https://github.com/okuuva/auto-save.nvim , we introduced a fork that solves your problems :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants