Packer.nvim: Detail keybinding in update display not working with table

[clason]

Since the last refactor/improvement, pressing enter on an updated plugin in the list no longer shows the specific commits in that update. (It's a bit hard to test since it relies on actual changes in plugins.)

I suspect that this is due to the fact that I pass the plugins as a single table to the new startup function?

Here's the relevant lua code:

vim.cmd [[packadd! packer.nvim]]
vim._update_package_paths()

local plugins = {
  {'wbthomason/packer.nvim', opt = true},
  'lervag/vimtex',
  {'nvim-treesitter/nvim-treesitter', opt = true},
}

local config = {
  display = {
    open_cmd = '25new [packer]',
  }
}

return require'packer'.startup {plugins, config = config}

[wbthomason]

Hmm. I was able to repro this once, but not any longer. Do you know what specific commit you were on when you first noticed the bug?

[clason]

Not really, but it must have been one of those from yesterday. My first instinct was to bisect it, of course, but you can't test it without updates to a repository... (or does packer behave similarly if you have a local git repo? that would be easy to test then.)

[wbthomason]

Well, you can simulate updates to a repo by going to the local clone and checking out an earlier revision (e.g. git checkout HEAD~1); packer will update accordingly. But I can't seem to replicate the error by doing that...

[wbthomason]

Ah! I got it. I couldn't reproduce the issue because I accidentally fixed it lol.

In fixing #19, I missed a require'packer/display' in the keybinding for the detail display. As @tjdevries noted in #19, using require with . vs / loads different modules (from the perspective of the Lua module system), so the keybinding was loading a different version of the display module with no connection to the open display.

tl;dr: Lua require semantics are strange.

[clason]

Yep, fixed, thank you! Accidental fix, best fix :)

[tjdevries]

hehe :) the string inside of require gets literally put into package.loaded I think, so that's why I just force myself to only use the . notation style.