":tab G" does not work when lazy-loading Fugitive with packer.nvim

[Hubro]

This is my packer.nvim config for Fugitive:

  -- {{{ fugitive.vim - Premier Git plugin for Vim
  use {
    "tpope/vim-fugitive",
    opt = true,
    cmd = {
      "G", "Git", "Gdiffsplit", "Gvdiffsplit", "Gedit", "Gsplit",
      "Gread", "Gwrite", "Ggrep", "Glgrep", "Gmove",
      "Gdelete", "Gremove", "Gbrowse",
    },
  }
  -- }}}

The plugin is only loaded when one of the listed commands are called. I try to do this for all my plugins, as it really helps startup time.

However, in this configuration, :tab G acts precisely like :G when called the first time:

If I close the split and call it again, it works.

If I load Fugitive eagerly (opt = false), it works as expected.

Any ideas why :tab ... doesn't work when lazy loading? Is there anything I can do to make it work, or is this a bug that must be fixed by either Fugitive or packer.nvim?

[tpope]

I haven't tried it but this screams packer.nvim bug. Or maybe just a packer.nvim limitation, as lazily loading commands is fundamentally impossible to do robustly without knowing the exact definition of those commands. I'm gonna go ahead and say this is unsupported and strongly discouraged.

[tpope]

CmdUndefined is an extremely old feature that hasn't kept pace with modern Vim (let alone Neovim), and abusing it like this to shave a couple of milliseconds off of the boot time is a bad idea. I'm honestly tempted to find a way to break it entirely, just to stop people wasting their time on it. You're breaking all sorts of things; :tab G is just the one that's obvious to you given your usage habits.

[Hubro]

Just to clarify, are you arguing that the entire concept of lazy loading plugins is a waste of time, or just that using CmdUndefined is a bad way of achieving it?

[tpope]

I am arguing it is a waste of time for Fugitive in particular, which defines in its plugin file not just commands but maps, autocommands, a public API, and integrations with other plugins. The bulk of the implementation is already lazily loaded via the autoload file. The main plugin file could probably be whittled down a bit more, since we now do lazy repo detection in addition to lazy initialization, but I would expect the ROI there to be pretty small.

And I think this is probably true of many if not most modern plugins. But I would not say it is a universal truth.

[Hubro]

I am arguing it is a waste of time for Fugitive in particular, which defines in its plugin file not just commands but maps, autocommands, a public API, and integrations with other plugins. The bulk of the implementation is already lazily loaded via the autoload file. The main plugin file could probably be whittled down a bit more, since we now do lazy repo detection in addition to lazy initialization, but I would expect the ROI there to be pretty small.

And I think this is probably true of many if not most modern plugins. But I would not say it is a universal truth.

Right, I see. When you put it that way, it does seem like a bad idea (and unnecessary) to lazy load Fugitive. In general I don't expect plugins to have put this much effort into optimisation 😄

[tpope]

The main plugin file could probably be whittled down a bit more, since we now do lazy repo detection in addition to lazy initialization, but I would expect the ROI there to be pretty small.

Make that "negligible", at least with a warm disk cache. If you eliminate all command, map, and autocommand declarations, the plugin takes less than a millisecond to load.

This suggests you might see some small gains if you :let g:fugitive_legacy_commands = 0, as that will cut down on the number of commands defined. (This is harder to benchmark so I didn't bother.)