Packer.nvim: Some edge cases leading to cryptic errors

[gwerbin]

Hi, thanks for the great plugin manager!

I found a few rough edges where the user "falls through" to Packer internals, leading to cryptic errors. Hopefully this report is helpful in future development.

System details

uname -orsv output: Linux 5.8.0-2-amd64 #1 SMP Debian 5.8.10-1 (2020-09-19) GNU/Linux

Packer commit: 237a134d5144f9f99df1a2f5bb29950c3d0ed795

nvim --version output:

NVIM v0.5.0-746-gf7cc3ae0b
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-5 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/travis/build/neovim/bot-ci/build/neovim/build/config -I/home/travis/build/neovim/bot-ci/build/neovim/src -I/home/travis/build/neovim/bot-ci/build/neovim/.deps/usr/include -I/usr/include -I/home/travis/build/neovim/bot-ci/build/neovim/build/src/nvim/auto -I/home/travis/build/neovim/bot-ci/build/neovim/build/include
Compiled by travis@travis-job-14258239-027b-4892-8d10-88b6f65b3f23

Features: +acl +iconv +tui
See ":help feature-compile"

system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "
/home/travis/build/neovim/bot-ci/build/neovim/build/nvim.AppDir/usr/share/nvim
"

Run :checkhealth for more info

Problem 1: quitting Packer too fast?

When I run nvim +PackerCompile +PackerUpdate +qall, I get a bunch of the following error repeated over and over:

Error executing vim.schedule lua callback: .../nvim/pack/packer/opt/packer.nvim/lua/packer/display.lua:130: Expected 4 arguments

Removing +qall (i.e. not immediately closing Neovim) eliminates this. Maybe there needs to be some kind of special-case check in place for this.

Note: the error only appears for PackerUpdate and not PackerInstall. I tried adding +'sleep 1' to the command line before +qall but that didn't change the result.

Problem 2: invalid cmd option

When the cmd option in packer.use is not a valid command (In this case I wrote cmd = ':Foo' instead of cmd = 'Foo'), the following error appears:

Error detected while processing /home/nms/.config/nvim/plugin/packer_compiled.vim:                               
line  172:                                                                                                       
E183: User defined commands must start with an uppercase letter

Hopefully there's a better way to handle such a situation in the compiled plugin script. It's not that hard for an experienced Vim user to go into the compiled source and figure out what's wrong, but it's still not an ideal way to report the error.

Problem 3: unknown or private Github repo

I wrote 'Shougo/denite.vim' instead of 'Shougo/denite.nvim' by accident. Then the command :PackerInstall completely froze, printing the Git "enter username" prompt at the top of the Packer window. I had to gracelessly close my terminal tab, I couldn't get Vim or the shell to respond any other way. I have not tried to replicate this in a GUI frontend.

As with Problem 2, I'm not sure how to fix the user experience here. An experienced Git user (who is also observant enough to notice that the top line of the window has changed) has certainly seen this prompt before, so it's not hard to infer the source of the shell hanging. But this is still quite a nasty error to encounter.

[tami5]

I agree with @gwerbin I just faced problem 3 and my vim instance completely froze

[wbthomason]

Thanks for these reports!

Problem 1 is interesting. Just to confirm, you're using the latest version of packer, right? Line 130 in display.lua is a function call that definitely takes (and receives) 3 arguments, so that error message is unexpected.

I will fix Problem 2 by checking for colons at the start of commands; that's easy enough.

Problem 3 is irritating; it has been reported before (see #26 and others). I'd hoped it was fixed an earlier change I made, but I guess not. I'll try to figure out what I can do to fix this/what other package managers do to prevent it.

[gwerbin]

Thanks for the quick response!

@wbthomason I'm not sure. This is the most recent commit in git -C ~/.config/nvim/pack/packer/opt/packer.nvim log:

commit 237a134d5144f9f99df1a2f5bb29950c3d0ed795 (HEAD -> master, origin/master, origin/HEAD)
Author: Wil Thomason <[email protected]>
Date:   Tue Sep 29 10:26:20 2020 -0400

Which is the same as the latest commit on Github master: https://github.com/wbthomason/packer.nvim/commit/237a134d5144f9f99df1a2f5bb29950c3d0ed795. So it must be the latest unless there are fixes that have not been pushed, or unless I should be using a different branch.

[gwerbin]

Also -- I found that sometimes Problem 1 occurs after PackInstall, usually only when new packages are being installed. Is there some obscure code path that might be triggered when the Packer window is never shown in a GUI or terminal?

[gwerbin]

For Problem 1, use GIT_ASKPASS=true as per https://stackoverflow.com/a/64319771/2954547 in order to run the true program as a way to pass in a null password and there silently fail the password prompt. See also https://git-scm.com/docs/gitcredentials.html#_requesting_credentials.

I am also very curious how Vundle, Vim-Plug, VAM, Dein, Minpac, etc. (did I miss any? :slightly_smiling_face:) handle this same scenario. Or do they have the same problem of showing the password prompt, but without the specific nasty UI freeze experienced by Packer?

[wbthomason]

It looks like you're on the right commit. I'll try to reproduce Problem 1 and see if I can print a more useful diagnostic.

For Problem 3: I've considered doing that (from the same StackOverflow post), but I don't know that true exists on Windows systems as well (and I'm not sure of the equivalent - some people say (exit 0) will work, while others claim it does not).

As for the other plugin managers, I'm not sure. Certainly none of them pass GIT_ASKPASS in the environment for their jobs (that I can find). The main difference seems to be that they use jobstart or similar, whereas packer uses luv.spawn directly (but seemingly equivalently?)

I still need to look into it more; I'm really confused as to why this hasn't been an issue for other plugin managers.

[gwerbin]

Someone on Stackoverflow just recommended GIT_TERMINAL_PROMPT instead. https://www.git-scm.com/docs/git#Documentation/git.txt-codeGITTERMINALPROMPTcode

[wbthomason]

Thanks, that's good to know about.

Look for a few PRs in (hopefully) the next couple of days fixing these issues.

[wbthomason]

lol @ me for saying I'd get to this in "the next couple of days".

(1) should be fixed by #107 - could you (@gwerbin) test this PR if you get a chance?
(3) should've been fixed already by #91
I haven't done anything for (2) yet, but haven't forgotten.

[kassio]

I'm also having similar problems:

Error detected while processing /Users/kassioborges/.config/nvim/plugin/packer_compiled.vim:
line  162:
E183: User defined commands must start with an uppercase letter
line  163:
E182: Invalid command name
[packer] Finished compiling lazy-loaders!

The line 162 on the compiled file has:

command! -nargs=* -range -bang -complete=file cd app && yarn install call s:load(['markdown-preview.nvim'], { "cmd": "cd app && yarn install", "l1": <line1>, "l2": <line2>, "bang": <q-bang>, "args": <q-args> })

[kassio]

If I remeve the line 162, then I get E182: Invalid command name with the next compiled command:

command! -nargs=* -range -bang -complete=file :TSUpdate call s:load(['nvim-treesitter'], { "cmd": ":TSUpdate", "l1": <line1>, "l2": <line2>, "bang": <q-bang>, "args": <q-args> })

[wbthomason]

@kassio Could you please share the relevant snippet of your config?

[wbthomason]

From the error, I'm guessing you may be confusing the cmd and run keys?

[kassio]

@wbthomason that's right! Sorry for the noise, thanks for the help. It's working now.

[gwerbin]

I think the +qall issue might be fixed. But now :PackerUpdate freezes on 47/119 packages. Not sure if it's related and not sure what additional debugging info I can provide. Not sure if it's actually updating in the background and just failing to update the UI, or if the updates are actually not proceeding.

[wbthomason]

@gwerbin: To clarify, is this :PackerUpdate in headless use or in the TUI?

[gwerbin]

In the TUI. It only started happening recently. I was getting warnings about 'redrawtime' running out. Maybe this should be a new/separate issue, but I wanted to flag it here in case it was related to whatever changes were made.

[wbthomason]

Fascinating. I have no idea what might cause that. If you have a chance to use git bisect to pin down when this started, that would be great - or if you have a minimal config to reproduce the issue.

[gwerbin]

I'll have to block out some time for that, not sure I'll be able to get to it. However it looks like with --headless there is no freeze, the q command works in the TUI, and I checked a few of the individual packages which all were up-to-date in Git. So I think it's just a visual bug.

It sounds like all 3 of my original issues have been resolved (thank you!) so I will close this. I will open a new ticket for the visual bug once I have a chance to look into it more.

[wbthomason]

Strange, ok. I don't suppose :messages shows you anything? No worries if you can't make time to do the bisect; I know that's a lot of work. I'll let you know if I manage to repro otherwise.