bug: Autocommand (defined in autocommand) not executed

[scajanus]

Did you check docs and existing issues?

• I have read all the lazy.nvim docs
• I have searched the existing issues of lazy.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.9.4

Operating system/version

MacOS Ventura 13.6

Describe the bug

Autocommand like:

autocmd BufRead * echom "hello" | au FileType <buffer> ++once echom "there"

does not trigger the FileType autocmd when opening Neovim.

The actual autocmd I was trying to use was the one from :h restore-cursor:

    autocmd BufRead * autocmd FileType <buffer> ++once
      \ if &ft !~# 'commit\|rebase' && line("'\"") > 1 && line("'\"") <= line("$") | exe 'normal! g`"' | endif

Steps To Reproduce

1. Start Neovim with nvim -u repro.lua repro.lua

Expected Behavior

Both autocommands get executed.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
vim.cmd([[autocmd BufRead * echom "hello" | au FileType <buffer> ++once echom "there" ]])

[scajanus]

Related: #858

[ericvw]

I can also confirm the issue exists. I ran into this when attempting to port to lazy from packer.

[ericvw]

I figured out why the snippet in :h restore-cursor doesn't work with lazy, in some cases 😉.

What

    autocmd BufRead * autocmd FileType <buffer> ++once
      \ if &ft !~# 'commit\|rebase' && line("'\"") > 1 && line("'\"") <= line("$") | exe 'normal! g`"' | endif

does is create a one-time executed autocommand when the FileType event triggers.

However, lazy is invoking preemptively

lazy.nvim/lua/lazy/core/loader.lua

Line 100 in 83493db

M.source(vim.env.VIMRUNTIME .. "/filetype.lua")

when loaded (initially added in ffcd0ab). Thus, if the restore cursor autocommand is defined after lazy is loaded, the FileType event has already been triggered.

I'm unsure if lazy should load Neovim's filetype.lua runtime preemptively. I understand it was to address #35; however, it seems strange for lazy to compensate for an issue that is rooted with Neovim and its handling of filetype. While still entirely up to the maintainers of lazy, reverting this change and letting Neovim and the plugin authors address how to approach this seems like a good idea. The generic workaround for end users is to invoke the equivalent of :filetype plugin indent on at the top of their configuration to ensure that filetype is set before any other configuration is defined — a recommendation by the Neovim maintainers I've seen across a couple of issues.

For those who are impacted by this, you can update the :h restore-cursor by removing autocmd FileType <buffer> ++once to trigger the Vimscript on BufRead because ft will be set due to lazy invoking filetype.lua. Alternatively, reordering when lazy is loaded and the autocommand is defined also works.

For the history of why the restore cursor snippet has diverged from vim, see neovim/neovim#15536 (comment).

[scajanus]

Thanks for looking into it! My workaround for this specific case was to keep using BufReadPost without ++once, which I think was the documented version in Vim: https://vimhelp.org/usr_05.txt.html#restore-cursor.

This means the autocmd is firing more often than necessary, but I can live with that for now as it doesn't break anything or prevent this from working. I imagine there are autocommands where this would be an issue, and of course it would be nice if the documented one for Neovim would work :)