Execution order conflict in mixed Vimscript and Lua configurations

Direct answer to the question

Neovim does not automatically load both init.vim and init.lua at startup. If an init.lua file is present, it is used and init.vim is ignored unless you explicitly source it. Consequently, any execution‑order conflict only occurs when you deliberately source the other language’s file (for example, lua require('my_vim_config') inside init.lua or source ~/.config/nvim/init.lua inside init.vim).

How priority is resolved when both languages touch the same option

When you have manually sourced both, the order in which autocmds are defined determines the order they run for a given event. Neovim stores autocmds in a list; when an event fires, callbacks are invoked in the exact sequence they were registered. Therefore:

• If a Vimscript autocmd is defined (or sourced) before a Lua autocmd that modifies the same global option, the Lua callback runs later and its change will overwrite the Vimscript change.
• Conversely, if the Lua autocmd is defined first, the Vimscript callback runs later and overwrites the Lua change.

This rule applies to any event (BufReadPre, VimEnter, etc.) and to direct option changes made outside of autocmds: the last executed statement wins.

Ensuring a Lua block runs after all legacy Vimscript has initialized

To guarantee that your Lua code executes after every Vimscript plugin and setting has finished, use one of the following documented mechanisms:

1. VimEnter autocmd – fires after all configuration files and plugins have been loaded.

vim.api.nvim_create_autocmd('VimEnter', {
  callback = function()
    -- Your Lua logic that must run last
  end
})

1. vim.schedule() – defers the callback to the next event‑loop iteration, ensuring any pending Vimscript operations in the current cycle complete first.

vim.schedule(function()
  -- Code that runs after Vimscript finishes
end)

1. Explicit sourcing at the end of init.vim – if you keep init.vim as the primary entry point, place lua require('my_lua_setup') as the very last line.

Verification and debugging

To confirm which script last modified an option:

• :verbose set <optionname> – shows the current value and the file/line that last set it.

To inspect the order of registered handlers for a specific event:

• :autocmd <EventName> – lists all callbacks in the order they will be executed.

If you are using a plugin manager that loads plugins asynchronously (e.g., packer.nvim with lazy loading), the exact timing may shift; in that case, please confirm whether your plugins are loaded lazily or eagerly, as that can affect the recommendation.