Packer.nvim: Bug: module causes error

Created on 17 Apr 2021  路  27Comments  路  Source: wbthomason/packer.nvim

Packer version: 43d9f53c2bf3a9d6680097ebcfb44cd426c7ab80

I was trying to load telescope with module config. But I got the following error.


Error message

Error running config for telescope.nvim
Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:43: [string "..."]:0: loop or previous error loading mod
ule 'telescope'
Please check your config for correctness
Error running config for telescope.nvim
Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:43: [string "..."]:0: loop or previous error loading mod
ule 'telescope'
Please check your config for correctness
Error running config for telescope.nvim
Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:43: ...k/experimental/opt/telescope.nvim/lua/telescope/i
nit.lua:39: loop or previous error loading module 'telescope.config'
Please check your config for correctness
Error running config for telescope.nvim
Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:43: ...k/experimental/opt/telescope.nvim/lua/telescope/i
nit.lua:39: loop or previous error loading module 'telescope.config'
Please check your config for correctness
Error running config for telescope.nvim
Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:43: ...k/experimental/opt/telescope.nvim/lua/telescope/i
nit.lua:39: loop or previous error loading module 'telescope.config'
Please check your config for correctness
Error running config for telescope.nvim
Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:43: ...k/experimental/opt/telescope.nvim/lua/telescope/i
nit.lua:39: loop or previous error loading module 'telescope.config'
Please check your config for correctness
Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:66: Vim:E492: Not an editor command: Telescope
Please check your config for correctness
Press ENTER or type command to continue

Minimal config

require('packer').startup(function()
  use { 'nvim-telescope/telescope.nvim',
    opt = true,
    module = 'telescope',
    cmd = 'Telescope',
    config = function()
      require('telescope').setup()
    end,
    requires = {
      'nvim-lua/popup.nvim',
      'nvim-lua/plenary.nvim',
    },
  }
end)


Preface

I was using octo.nvim . It requires telescope to function . It provides an extention for telescope to int3rface with it . Previously I was configureing octo.nvim liek following

  use {'pwntester/octo.nvim',
    after = 'telescope.nvim',
    cmd = 'Octo',
    opt = true,
    config = "require('telescope').load_extension('octo')"
  }

It was working fine before . But it started giving error in telescope loading that octo extention wasn't found (This might be a separate bug). I thought module might be a solution to this issue . But I'm getting new set of errors with module 馃槄

bug

All 27 comments

Thanks for the report! I'm pretty sure this is a bug with module lazy-loading - I can reproduce it on my system (thanks for the minimal reproduction example!) and will see if I can track the issue down.

Ok, I think there's a logic bug in how we decide which modules we need to load and which we need to pass off to a default loader. I'll see if I can throw together a PR to fix it.

Thanks for looking into it :) Hope you find a fix soon .

Ok, I think there's a logic bug in how we decide which modules we need to load and which we need to pass off to a default loader. I'll see if I can throw together a PR to fix it.

This was actually wrong...right now, it seems like (1) there's an unexpected interaction with transitive-optness for requires plugins causing plenary to not load when it needs to and (2) for some reason I haven't been able to figure out yet, the Telescope command isn't getting created after packadd, which should be impossible...

Doing the actual module lazy loading here works, e.g. :lua require('telescope') is fine. It's just when we try to run :Telescope to lazy-load that things break. But this only happens when you have both module and cmd lazy-loaders.

But this only happens when you have both module and cmd lazy-loaders.

keys too . Lazy loading on keymaps have the same error . Probably the same issue

keys + module, or keys + cmd?

keys + modules . Though now looking back I was mapping to Telescope command . like nnoremap <leader>t :Telescope builtin<CR> . So probably Telescope command not being around is the issue . But really how packadd should handle it 馃

Can I make a suggestion ? Can we have an option in custom initialization to disable compiling all togather and use the config instead ? Like I'm loading the config on startup anyway if packer just uses that to manage plugins it'll be way less hassle . I found it really hard to mimalize the config to reproduce the bug due to packer being real stuborn about holding onto old configs :P . Even with nvim -u New_config.lua

Automatic recompilation is already in the works, which should do away with that whole class of hassles/problems. The argument against just adding an option too is that it would require duplicating a lot of the logic in the compile module to generate the same lazy-load autocommands, conditional load tests, etc. Doable, but would require significant refactoring effort that I think is better put into making compiles automatic.

Ok, fixed the issue! It had to do with the module loader getting implicitly invoked before we'd marked the plugin as loaded via the command loader. I'll clean things up and push a PR in a few minutes.

Automatic recompilation is already in the works

That would probably work . If it makes easy to switch between configs easily or have multiple configs at the same time :)

The argument against just adding an option too is that it would require duplicating a lot of the logic in the compile module to generate the same lazy-load autocommands, conditional load tests, etc. Doable, but would require significant refactoring effort that I think is better put into making compiles automatic.

Seems like a valid argument me . No need to write the whole thing again for this .

I'm going a bit off topic here . But can highlights be decoupled from redraw time ? After redraw time highlights get disabled .

Also is there a way to disable a plugin without deleting it ?

These seems to trip me sometimes :)

But can highlights be decoupled from redraw time ? After redraw time highlights get disabled .

Sorry, I'm not sure I understand what you mean? Which highlights, and what redraw time?

Also is there a way to disable a plugin without deleting it ?

Yes - you can manually mark it opt = true (note that you do not need to mark lazy-loaded plugins opt manually) to disable it without deleting it. Or add cond = false to always skip loading it.

Sorry, I'm not sure I understand what you mean? Which highlights, and what redraw time?

Highlighting in PackerSync manu . redrawtime is a vim option . Packer turns off highlighting if PackerSync takes longer than redrawtime . Which seems really weird to me .

add cond = false to always skip loading it.

That's what I'm looking for :)

It'll actually be nice to have a command that loads a specific plugin .

Say something like

:PackerLoad telescope.nvim

loads telescope plugin (when opt=true) with it's setup and config . What do you think ? For example I have most of the plugin configuration done in packer config . To add a plugin I can do packadd but that means all the configs won't be loaded .

Telescope command itself is created with a require can it be the reason it conflicts with module ?

It'll actually be nice to have a command that loads a specific plugin .

Say something like

:PackerLoad telescope.nvim

loads telescope plugin (when opt=true) with it's setup and config . What do you think ? For example I have most of the plugin configuration done in packer config . To add a plugin I can do packadd but that means all the configs won't be loaded .

This is a solid idea, I like it! Could you please make a new issue for it (or a PR if you're willing - I'd be happy to help guide)?

Telescope command itself is created with a require can it be the reason it conflicts with module ?

More or less. As detailed in the PR I made, what happens is that this line tried to require telescope, which (because we hadn't marked telescope as loaded yet) re-ran the load function and caused its config to run, which caused the problem. The PR fixes this by moving the loaded mark earlier.

This is a solid idea, I like it! Could you please make a new issue for it (or a PR if you're willing - I'd be happy to help guide)?

I'm willing to implement it but currently I really don't have time. For now I've opened an issue . If no one implements it before me I'll make a pr :]

Highlighting in PackerSync manu . redrawtime is a vim option . Packer turns off highlighting if PackerSync takes longer than redrawtime . Which seems really weird to me .

This might be a neovim thing .
Have you never seen this message ?

'redrawtime' exceeded, syntax highlighting disabled

If not try setting redrawtime to a lower value (default is 2000) if you device is too fast for it to occur 馃檪

may be

:set redrawtime=1
:PackerSync

1 has to do it 馃榿

Edit:

Wait 1 gets rid of syntax highlighting all togather(Even from buffers) . Definatly neovim disableing highlighting. But how come packer takes >2000ms to highlight . Haven't seen it occur in any other plugin .

redrawtime in Docs :

'redrawtime' 'rdt'
'redrawtime' 'rdt' number (default 2000)
global
Time in milliseconds for redrawing the display. Applies to
'hlsearch', 'inccommand', :match highlighting and syntax highlighting.
When redrawing takes more than this many milliseconds no further
matches will be highlighted.
For syntax highlighting the time applies per window. When over the limit syntax highlighting is disabled until CTRL-L is used.
This is used to avoid that Vim hangs when using a very complicated pattern.

I haven't ever seen issues with syntax highlighting and packer, but let's open a separate issue for tracking down that behavior?

I've very infrequently noted this syntax highlighting issue as well heres a quick screen grab
image

I've very infrequently noted this syntax highlighting issue as well heres a quick screen grab

yep that's the one . I actully have it quite often . Mostly in PackerSync when lots of plugins are being upgraded .

Does module loading still work after this initial change. I think on my end it seems to have stopped working

@akinsho It worked for me when I was testing #300. Do you have a failing example?

@wbthomason apologies was a false alarm not sure what was going on there/what I did but just retried it today and it works.

Ok, thanks!

@shadmansaleh Can you please open a new issue for the syntax timeout problem?

@shadmansaleh Can you please open a new issue for the syntax timeout problem?

323

Was this page helpful?
0 / 5 - 0 ratings