Watching additional files only reloads on first change from Neovim

paul-hansen commented 3 weeks ago

Description

I have some code in my README.md file that I test using cargo test --doc using this trick. I tried adding a job for doc tests and told bacon to watch the README.md but it seems to only reload on the first change if I edit the readme from Neovim. Any additional changes to the readme it does nothing. Changing other files still works.

Here's the job definition in my project's bacon.toml

[jobs.doctest]
command = [
    "cargo", "test", "--doc", "--color", "always",
    "--", "--color", "always",
]
watch = ["README.md"]
need_stdout = true

I also tried with a text file in my project root named test.txt and got the same result as the README.md

Reproduction Steps

Create a project with a readme, init bacon, add bacon job with watch=README.md and run it.

cargo new --lib test_bacon
cd test_bacon
bacon --init
printf "[jobs.doctest]\ncommand = [\n    \"cargo\", \"test\", \"--doc\", \"--color\", \"always\",\n    \"--\", \"--color\", \"always\",\n]\nwatch = [\"README.md\"]\nneed_stdout = true" >> bacon.toml
bacon doctest

In another terminal run touch README.md in the project directory multiple times to see that bacon is reloading correctly.
Open README.md with neovim with factory settings (--clean) and have it automatically save and close.
```
nvim --clean README.md +w +q
```
Observe that touching the README.md file or writing to it in any way no longer reloads bacon.

System Info

Bacon: 3.1.2 (also tried 3.1.1, 3.1.0, and 2.21.0 with same result) Neovim: v0.10.2 Terminal: Wezterm 20240203-110809-5046fc22 EndeavorOS (Arch based distro) with KDE Plasma 6.2.2

Bacon is great!

Thanks for bacon, it's great! Love the nextest integration and the config reloading! Hope you don't get burnt out from all the people coming from cargo watch :heart:

Canop commented 3 weeks ago

Can you check whether the problem is answered by https://dystroy.org/bacon/community/#vim-neovim-support ?

paul-hansen commented 3 weeks ago

I'm sure that's it, sorry for missing that.

I'll close this for now but if I get bored in the future would you be interested in a PR with a fix/workaround or have you already investigated and decided against it? Guessing it'd be something like watching the parent directory for changes involving the file's path instead of the actual file since the issue seems to be that inotify follows the file to it's new location if moved and that doesn't really make sense here.

Thanks again!

Canop commented 3 weeks ago

I'm sure that's it, sorry for missing that.

No worry. This neovim related piece of help should obviously not be in the FAQ at the bottom of the "Community" page. I should reorganize the site. I'm not yet sure of what would be the good organization, though.

Regarding PR, be aware that I'm very careful this them, and I prefer to first have serious discussions on the diagnostic and solution design. Once again I had today to refuse rather good PR. See https://dystroy.org/blog/contributing/

paul-hansen commented 3 weeks ago

From the bacon faq:

set nowritebackup

This doesn't prevent vim from keeping copies during editions, it just changes the behavior of the write operation and has > no practical downside.

:help writebackup seems to contradict this though:

Make a backup before overwriting a file. The backup is removed after the file was successfully written, unless the 'backup' option is also on. 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).

Perhaps the bacon docs meant to suggest set backupcopy=yes which is what changes the behavior to use a copy instead of a rename.

When writing a file and a backup is made, this option tells how it's done. This is a comma-separated list of words.

The main values are: "yes" make a copy of the file and overwrite the original one "no" rename the file and write a new one "auto" one of the previous, what works best

Some people still may want to use nowritebackup if they are religious about making git commits anyway and don't care about possibly loosing progress since their last commit. Seems like you would want to make that potential of lost data clear when suggesting that though. It's possible I'm missing something, corrections are appreciated.

tldr;

To fix this you add one of these to your init.lua file:

if you care a lot about not loosing changes vim.opt.backupcopy = "yes", saves will be slower.
if you want neovim to save fast and don't care if you potentially (nvim swap might save you) have to use your last git commit if it crashes, vim.opt.writebackup = false

Canop / bacon