It was a long, winding road to reach the root cause. Jump to "Final Update" below if you're only interested in the destination, not the journey.
Per :h FileType
the FileType
event doesn't do anything unless 'filetype'
is set. The standard way to set that is to have this in your vimrc/init.vim:
:filetype on
This "enables file type detection".
You don't have anything in your init.vim so that's surely why this stuff isn't working "out of the box". Your Session.vim
file, which contains a bunch of config, likely was created when filtype was enabled. That's why things work after you source it.
BTW, you should be doing autocommands like this:
augroup myautocmds
autocmd!
au FileType * echom "test"
augroup END
This allows you to safely re-source the file containing your autocommand(s).
Update: Okay, current state of affairs is that everything is working with above, generally speaking, but echom
doesn't not produce any visible output. I use echom
in autocommands in Vim but I'm wondering if filetype
event specifically poses a problem. Other actions, e.g. setting a variable, work fine. Investigating further...
Update 2: After it's all said and done it looks like it boils down to this: echom
with FileType
autocommands is not reliable. Works with other event types. Works with Vim. Not with Neovim and file type. If OP happened to use a different command (e.g. set a variable and checked the value) they might not have ended up here at all.
(Opening a bug with Neovim might be prudent.)
Update 3: Just to formalize the conclusions I automated some tests so I could be sure that there is a discrepancy between Neovim's behavior and Vim's...as opposed to some human error leaking in. Tests were parameterized over several permutations of auto-command event types, auto-command patterns and minor variations of the actual commands run. Specifically, I tried both direct and indirect calls to echom
. (Indirect: echom
put in a function and the autocommand calls the function.) For the indirect cases I also wrapped the echom
calls in redir
so, in theory anyways, the messages would appear in both mess
command output and in a temporary file.
Results didn't turn up any surprises...
Vim (and gvim) consistently showed echom
messages in real-time and when viewed with mess
for all tested event types as long as the pattern used was valid. For the indirect command calls all messages also showed up in the redir
files.
Neovim had less consistent results. For event type BufEnter
everything worked exactly as it did for Vim. For the FileType
, BufRead
and BufReadPre
events the messages never showed up real-time or in mess
output. The only cases that the echom
call could be verified to have occurred at all with these events is with the indirect/redir test variations. In those cases the echom
output always appeared in the redir
file.
Anyways, I believe this concludes matters as far as StackExchange activities go. Next step, if someone wants to move things forward, would be to see what the Neovim maintainers have to say about it.
Final Update: Apparently this is due to a different default than Vim for 'shortmess'
and removing F
from its value will match Vim's behavior. Doesn't make me feel too much better about things as the behavior (affecting this autocmd but not that autocmd) is apt to cause confusion. (There have been a number of bug reports filed over this thing.)