Autosave.nvim makes my undotree dirty

[Lakshamana]

Hello, there. Awesome plugin!

The issue I'm bringing here is that somehow whenever I type u to undo on Neovim (specs on below image) the expected previous edit does not appear. Instead it blinks the [+] on the low bar like a new edition was being made and then when I check my undotree it is full of empty edition entries, check it out:
This is my nvim configuration:

This is the undotree:

Pointing it to one of edits entry (please notice, timestamps would change due to time I'm taking shots and editing this issue as well)

Immediately previous edit entry:

As you see this is what I called empty edit entries.

Now, this is my basic conf to reproduce such error (init.vim):

local autosave = require("autosave")

autosave.setup(
    {
        enabled = true,
        -- execution_message = "AutoSave: saved at " .. vim.fn.strftime("%H:%M:%S"),
        execution_message = "",
        events = {"TextChanged", "InsertLeave"},
        conditions = {
            exists = true,
            filetype_is_not = {},
            modifiable = true
        },
        write_all_buffers = false,
        on_off_commands = true,
        clean_command_line_interval = 0,
        debounce_delay = 135
    }
)
EOF

Please notice, I tested with this plugin enabled and disabled and got not issues at all by running u with this plugin disabled. This would let me conclude the issue is with autosave.nvim. So the basic outcome of this issue is that it takes a lot of u tapping to get me the real previous editing.

Thank you!

EDIT: I don't know if this helps you but, leaving just "InsertLeave" the entry events seems to "resolve" the issue, albeit it will not save changes made on Normal Mode.

[pocco81]

Hey! As weird as this may sound, this is expected behavior. As you said, leaving only the InsertEnter event works well, that's because the culprit is TextChanged.

There is actually a warning about it in vim's doc:

Careful: This is triggered very often, don't do anything that the user does not expect or that is slow.

I too get this issue, but the issue is not the plug-in itself. Like you could just write a very simple one-line autocommand to save on TextChanged and you'll see the same behavior.

Sandly this is so random that it's hard to reproduce....

[Lakshamana]

@pocco81, the current config for your own plugin is exactly the same as the docs? The weird thing is, I wouldn't notice nothing wrong in the past few days, then suddenly things stop working the way it should be =\

Thank you for your fast response here, btw

[pocco81]

I wouldn't notice nothing wrong in the past few days, then suddenly things stop working the way it should be =\

As I said, this is very very random. But regardless of its nature it should only cause errors the buffer is saved while some other plugin needs to do some stuff with the unmodified buffer. This is actually the reason for the debounce_delay setting.

I actually remember having an problem with an autocompletion plugin (don't remember if it was that) that needed to read the unsaved buffer, so varying the delay worked.

Feel free to play around with both the events and the debounce_delay settings!

If it helps, here are some issues regarding undoing stuff when using an auto save type-of plugin:

• Undo does not work when using this plugin 907th/vim-auto-save#37
• Duplicate entry is created in undo history 907th/vim-auto-save#53
• Undo not working on go files when auto-save is enabled. 907th/vim-auto-save#51
• Undo list is modified for every repetition of a macro 907th/vim-auto-save#41