6

I'm on Archlinux with vim 8.2.2380. Since running updates yesterday, I'm getting W11 warnings periodically just by having a file open in a buffer which has changed on the FS (e.g. when opening log files with vim):

W11: Warning: File "/path/to/logfile.log" has changed since editing started
See ":help W11" for more info.
[O]K, (L)oad File:

Even worse, the warning is printed again a few seconds later if the file changed again. This did not happen before the update, and does not seem to be influenced by my (pretty minimalistic) vimrc as it also occurs on the root account that doesn't even have a vimrc. In case it matters I do set nobackup, nowb, noswapfile and nocompatible.

I've found a question dealing with disabling the warning when writing to a file, but I think the warning is useful when writing so I still want to see it in that case. I've also found an SO question advising to use autoread, but that does not work for me as I do not want to reload the file when it changed. Another advice, also stated in the W11 help entry, says this warning is not shown when buftype is not empty. However, I don't want to have to set the buftype manually each time I open a log file, and I'm not sure it's possible and/or a good idea to do this automatically for all log files (with various file endings such as .log, .txt, .out etc).

How can I configure vim to not produce any W11 warnings for files simply idling in a buffer? Summarized, I have the following additional requirements:

  • I do not want to automatically reload the file when it changes
  • I do not want to disable the warning when attempting to write to a file
  • I do not want a manual solution such as setting buftype by hand after opening a file
l4mpi
  • 855
  • 7
  • 17
  • 1
    Did you see :h FileChangedShell? – Matt Jan 22 '21 at 14:03
  • I wonder if updatetime is relevant? There's also :checktime. Not sure what caused the change in messaging to be more often, though if the file is changing W11 is the correct response. – D. Ben Knoble Jan 22 '21 at 14:04
  • @Matt thanks, creating an autocommand for that event seems to have suppressed the warnings. Took two attempts since I initially got the syntax wrong... Incidentally, what's the best way to do a "no-op" autocommand? I ended up doing if 1 < 0 | | endif but is there a smarter way? – l4mpi Jan 22 '21 at 14:55
  • @D.BenKnoble updatetime seems to be for the swapfile only. checktime looks like it's used to produce the warning and I don't see how it could be used to suppress it. And the warning doesn't occur "more often" as it didn't appear at all over the last decade with 3 different distros even when I've had log files open for multiple hours. Well, the autocommand seems to fix it so problem solved. – l4mpi Jan 22 '21 at 15:02
  • A single colon is perfectly valid "do-nothing" command. However, in this case you may also want to inspect v:fcs_reason and set v:fcs_choice accordingly. – Matt Jan 22 '21 at 15:24
  • Also narrowing event processing by file mask, e.g. FileChangedShell *.log might be also a good idea. – Matt Jan 22 '21 at 15:26
  • @Matt I simply never want to see the warning on any file ever if I'm not writing to it, so * is fine and I'm not interested in the reason or setting a choice. But thanks for making me aware of these parameters. – l4mpi Jan 22 '21 at 15:34

1 Answers1

5

This comment by Matt led me to the solution: creating an autocommand for the FileChangedShell event seems to suppress the warning. I ended up using the following no-op autocommand:

autocmd FileChangedShell * :
l4mpi
  • 855
  • 7
  • 17