vim double-triggers bacon v2.21.0 when saving a file

[narpfel]

When saving a file in vim (or neovim), vim will write to multiple files in the directory of the saved file. Here is a log for saving src/main.rs in neovim:

$ inotifywait --monitor src
Setting up watches.
Watches established.
src/ CREATE 4913
src/ OPEN 4913
src/ ATTRIB 4913
src/ CLOSE_WRITE,CLOSE 4913
src/ DELETE 4913
src/ MOVED_FROM main.rs
src/ MOVED_TO main.rs~
src/ CREATE main.rs
src/ OPEN main.rs
src/ MODIFY main.rs
src/ CLOSE_WRITE,CLOSE main.rs
src/ ATTRIB main.rs
src/ DELETE main.rs~

(Note that this doesn’t happen on tmpfs filesystems, there neovim directly writes the file. I can reproduce the shown behaviour on btrfs and ext4; I don’t have any other filesystems at hand.)

This means that with the new default for on_change_strategy introduced in #207, each save will run the current job (e. g. running the tests) twice. The old behaviour works well, so feel free to ignore this issue, but it might be nice to avoid retriggering anything in this situation (maybe by adding a timeout of a couple milliseconds?).

[Canop]

It looks like the problem you have is related to the write strategy of your vim installation.

You should be able to fix this by adding this in you (n)vim config:

set nobackup

[narpfel]

This is not really a vim-specific problem, many editors write backup files. Just a quick test with some editors (default configurations):

• Writes backup file/double-triggers bacon
  • vim/nvim
  • helix
  • gedit
  • kate
  • geany
  • Qt Creator
• Does not double-trigger bacon
  • vi
  • nano
  • kakoune
  • zed

set nobackup does not work around the issue for me (the output of inotifywait is not changed. Actually, upon reading the docs, nobackup is the default), but set writebackup does. However, it is documented with

        WARNING: Switching this option off means that when Vim fails to write
        your buffer correctly and then, for whatever reason, Vim exits, you
        lose both the original file and what you were writing.  Only reset
        this option if your file system is almost full and it makes the write
        fail (and make sure not to exit Vim until the write was successful).
        See backup-table for another explanation.

which I agree with and which is probably why the other editors behave this way as well.

[Canop]

All those saves happen in less than 1 ms, right ?

I wonder if this couldn't be solved with

• having the task start with a 1ms wait
• disregarding inotify events occuring during this wait

[Canop]

@narpfel Can you test with PR #233 ?