search

wbthomason / packer.nvim

A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
MIT License
7.72k stars 263 forks source link

Events causing `autocommand nesting to deep` #1163

Closed seblj closed 1 year ago

seblj commented 1 year ago

Observed behaviour

Using the event key causes an error: autocommand nesting to deep.

Expected behaviour

Should work like on v1

Steps to reproduce

Step 1: Have packer.nvim installed as an opt-package

Step 2: Use this minimal neovim config

vim.cmd.packadd('packer.nvim')

require('packer').add({
    { 'lewis6991/packer.nvim', branch = 'main' },

    { 'saecki/crates.nvim', event = 'BufRead' },
})

Step 3: Open a file and observe the error.

It seems to be because of vim.api.nvim_exec_autocmds(event, { modeline = false }) in packer.nvim/teal/packer/handlers/event.tl, because if I comment that out, it seems to work as expected with this minimal example. Don't know if it creates other problems by removing that line though.

packer files

Plugin specification table Post or link to a file containing your table of plugin specifications here, if you aren't able to provide a minimal reproducer
packer log file Post the contents of ~/.cache/nvim/packer.nvim.log here ``` [DEBUG 20:56:44 531297] ...are/nvim/site/pack/packer/opt/packer.nvim/lua/packer.lua:9: setup [DEBUG 20:56:44 1252614] ...are/nvim/site/pack/packer/opt/packer.nvim/lua/packer.lua:32: PROCESSING PLUGIN SPEC [DEBUG 20:56:44 1449194] ...are/nvim/site/pack/packer/opt/packer.nvim/lua/packer.lua:35: LOADING PLUGINS [DEBUG 20:56:44 1703063] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:107: Running loader for packer.nvim [DEBUG 20:56:44 1774067] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:124: Loading packer.nvim [DEBUG 20:56:44 28541060] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:107: Running loader for crates.nvim [DEBUG 20:56:44 28637480] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:124: Loading crates.nvim [DEBUG 20:56:44 29312841] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 29390160] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 29587039] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 29664088] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 29774203] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 29893510] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 29970328] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 30151885] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:44 30233172] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:98: Already loaded crates.nvim [DEBUG 20:56:50 468370] ...are/nvim/site/pack/packer/opt/packer.nvim/lua/packer.lua:9: setup [DEBUG 20:56:50 1198866] ...are/nvim/site/pack/packer/opt/packer.nvim/lua/packer.lua:32: PROCESSING PLUGIN SPEC [DEBUG 20:56:50 1406580] ...are/nvim/site/pack/packer/opt/packer.nvim/lua/packer.lua:35: LOADING PLUGINS [DEBUG 20:56:50 1676566] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:107: Running loader for packer.nvim [DEBUG 20:56:50 1752748] ...m/site/pack/packer/opt/packer.nvim/lua/packer/loader.lua:124: Loading packer.nvim ```
lewis6991 commented 1 year ago

What you've identified is most definitely the issue and I was already considering removing that line.

wbthomason commented 1 year ago

Yeah - see https://github.com/wbthomason/packer.nvim/commit/c89092c6667e0dfa741e721949571dd8d1c3d3e5#commitcomment-92257389 for some existing discussion.

@lewis6991: I'm not certain that we can get away with removing that line - if a plugin is expected to do something on the same event as it's being loaded with, I think we need to re-trigger the event (I don't believe that newly-sourced autocmds get added to the current list to run, if sourced during an autocmd event execution). We may just need to have a deleter for event specifically - although v1 just triggers the event again.

lewis6991 commented 1 year ago

if a plugin is expected to do something on the same event as it's being loaded with

In these cases, the plugin probably shouldn't be lazy loaded. As with everything, I'd like to udnerstand some real world use cases.

If a plugin really does need the event issued again, then we should probably just require users create a custom loader (via cond) so they can manage it properly by handling the intricacies of the specific event. Alternatively they can manually run the plugins function that is run on the event.

I think we need to re-trigger the event

Re-triggering the event has a chance of creating difficult edge case issues, since some plugins may rely on events happening when they actually happen. E.g. a plugin may be listening for events to progress a state machine, and issuing a fake event may put it into a bad state.

lewis6991 commented 1 year ago

I've commented it out for now just to quickly fix this issue.