The neovim model of using setup() makes lazy loading a bit trickier than traditional Vim.

Lazy loading is much easier with Vim’s model of configuring by setting variables. You just set variables in init.vim, and the plugin can auto-load when one of its functions is executed.

With lua this requires more orchestration; if many autocmd refer to the same plugin, they all need to explicitly remember to call setup().

Plug still gets the job done imo. But I'm also hopeful that since this one is builtin to the language it'll likely be end-game worthy for lots of users. I have tried it out and had a painless experience though I never did anything fancy like lazy offered.

Luckily this is the built in, official, blessed one. So it’s likely going to be the most widely supported and available. (Maybe not most feature rich though)

Lazy.nvim seems pretty triumphant. But yeah a lot of others are also supported by various plugins. Some unity would be nice, abstractly. But man, it's hard to have faith we're going to get as anything good fast and reliable as lazy.nvim. it could happen though!

I started using nixvim. I think I gave up around vim-plug. Trying to maintain reliably working config across multiple machines and OS was a nightmare.

I tossed pathogen in favor of git submodules in ~/.vim/pack/*/start/ in 2017 and it's still like that.

Just looked at my (private) dotfiles git history

- pathogen in 2011

- vundle in 2013

- vim-plug in 2017

Haven't moved since, Plug still does the job, even after I moved to neovim in 2021. Will probably move to the new built-in package manager once the dust has settled.

in Nix it's the same for as long as I remember, both on NixOS and nix-managed home-manager on MacOS and Linux:

      neovim = {
        enable = true;
        vimAlias = true;
        vimdiffAlias = true;
        defaultEditor = true;
        plugins = [
          pkgs.vimPlugins.fugitive
          pkgs.vimPlugins.fzf-vim
          pkgs.vimPlugins.vim-gh-line
          pkgs.vimPlugins.vim-gutentags
          pkgs.vimPlugins.nvim-lspconfig
          pkgs.pkgs-unstable.vimPlugins.vim-go
          pkgs.pkgs-unstable.vimPlugins.zig-vim
        ];
        extraConfig = builtins.readFile ./vimrc;
        extraLuaConfig = builtins.readFile (pkgs.replaceVars ./dev.lua {
              inherit (pkgs) ripgrep;
            }).outPath;
      }

This is the FOMO speaking. You don't have to switch if you don't want to.

New package manager is pretty slow right now, it's like 200ms to load nvim with lazy vim vs 1 sec with Pack.

I’m literally just using git with vim.

I have been staying on vim-plug where everyone seems to be moving on to lazy.vim. I was considering a weekend to migrate to lazy.vim sometime. But with this news, I might just have to wait for this plugin manager to drop.

Why? I’ve been using dein since it was released and haven’t needed to switch to anything (though I’ve noticed the momentum shifts quickly between different ones).

Similar here too. I'm on the lazy.nvim train too because it's componentized, powerful, and scalable. It would take me ages to get all of the stuff going that Just Works™ (pretty much) OOTB. Yes, even Copilot if you're into that sort of kinky code completion sharing with OpenAI/Microsoft everything you type.

I think I update Vundle like once every 3 years.

You're using an editor that is built to be configurable for people who enjoy endless configuration. This will not be the last config manager. You might as well ask JS community if Nextjs is the last JS framework

You're linking this all over the place so heads up, it links to an unrelated file in the diff.

[dead]

Seems like a plausible idea but working with clocks my first question would be "whose clock is it". Is it repository defined clock? My clock? Git remote’s clock?

AFAIK this can be used for hashes, but friends don’t let friends use clocks in software developments (unless it’s last resort).

I’m curious. What’s the risk of a supply chain attack? What are the privileges of a VIM plugin?

I thought that gives master as of your pull time, not nearest commit to that time, which seems very confusing (it isn’t reproducible, except for yourself). I think you need a more complicated git log —before=time for any semblance of reproducibility

Why not by SHA?

> If you track your config with git, you can track plugins with submodules. This has the added advantage of pinning the exact version (and tracking that version in for).

I did this for a year or so, with the motivation that submodules could replace all tool-specific package managers (for vim, tmux, zsh, etc.).

But honestly managing Git submodules felt like a chore compared to my old `vim-plug` setup. Basically because submodules are a neat concept but not implemented very ergonomically in Git. Eventually I just went back.

If someone has a setup using built-in vim pack that feels more ergonomic than vim-plug et al. then I’m very interested to hear.

I find myself enabling and disabling some plugins frequently and find it easy via the com config than the shell/filesystem . However, more importantly plugins can be activated easily based on file-type. Most plugin managers are anyway only a small wrapper around git, I guess.

And then ditching those packages unmaintained (like snacks).

// mini.nvim is a completely different author though and doesn't have to do much with lazy

I think he's pretty well placed to implent good interfaces following his paradigm, noticeably different than some other authors. I like it, so I often think his take is the best.

Snacks picker is now the best picker, for example.

> I think neovim would do better if they started integrating the core plugins like LSP, tree sitter

That's exactly what they're doing.

Both tree-sitter and LSP are built in and the primary LSP/tree-sitter plugins only bundle default LSP configurations and tree-sitter queries respectively. They're also planning to include tree-sitter query bundling into Neovim natively somehow, to make it even less reliant on the nvim-treesitter plugin.

They recently simplified the LSP configuration and to configure a new LSP you basically do this:

    vim.lsp.config("expert", {
      cmd = { "expert" },
      root_markers = { "mix.exs", ".git" },
      filetypes = { "elixir", "eelixir", "heex" },
    })

    vim.lsp.enable("expert")

I was the same and kept using vim for C/C++ development. vim-plug, gutentags (ctags manager), ALE did their job pretty well and I didn't bother to learn another way.

All that changed with web dev where you have to juggle with different syntaxes and tools... I decided I would just use a neovim distribution. I have tried many but Lunarvim (now inactive) and now Astronvim have served me well so far.

Same, but I'm guessing it'll settle down in the next 5-10 years.

That is a thing of beauty.

I recently migrated from lazy.nvim to vim.pack and it was way easier than expected:

https://github.com/azemetre/dotfiles/pull/61/files

I followed the work of another neovimmer where he was able to replicate deferring with vim.pack. Brought my startup time down to sub 100ms.

Definitely worth it to me as it's one less "core" plugin to maintain. Having things like telescope or trouble are one thing, it's quite another to rely on a plugin that changes the way neovim interacts with loading.

I agree if it at least can match lazy.nvim in features, which it so far doesn't. Stuff like pinning plugin versions, notifying about breaking changes and actual lazy loading are very useful.

I like the approach! I'd be interested in reading more. I might not fully adopt it but I m on a similar wavelength about stability. I don't want things to change unexpectedly, I just want my tools to just work consistently without surprises.

It is explained in that issue: https://github.com/neovim/neovim/issues/20893#issuecomment-1...

You joke, but a colleague tried to get me using nvim a few months ago, and after installing all the stuff he recommended, my first impression was that I was running emacs. It was busy, there were extra buffers all over the place, things kept popping up as I typed, and I wasn’t clear on how to get to normal mode. In sure this has as much to do with his config, which I copied without understanding it, as it does with nvim itself, but it felt very unfamiliar.

Vimotheé!!

Link to src?

I'm a Neovim user but I have to agree with the recommendation. If you've wanted to check out vim/emacs but were nervous Helix is a good place to start.

I do wish there was at least the option to use vim keybindings in Helix though. The Helix keybindings are mostly the same but just different enough to be annoying if you're already used to vim.

Edit: typo

I actually like Helix a lot too, but it is different than (neo)vim in a lot of significant ways. It feels like alternate-universe vim more than just better defaults. It also doesn't just not require scripting, it doesn't support scripting (yet). Very interesting in its own right but it might not be what you want if you're familiar with (neo)vim already.

I still have to interact with files on servers I don't control, so I still need to keep basic vim motions in my working set memory unfortunately

Can I use wasd for my movement keys?

On the neovim subreddit one of the core maintainers said that relying on users to lazy load plugins is an extremely poor practice and something that should be done by the author's of said plugins. It is just a matter of how you initialize your plugin/name-of-plugin.lua file.

Don't know if it helps but I recently migrated to vim.pack. With another neovimmer he helped me create a defer function and pack update. The only plugin I initially load is a dashboard while deferring everything else. Brought my startup time to sub 100ms.

https://github.com/azemetre/dotfiles/pull/61/files

Depending on the number of plugins you have, you may not notice the difference in practice. I certainly don’t but I’m very much on the minimal side of things. This all said I’m definitely of the school of thought that plugin developers should be responsible for ensuring their plugins are lazy loaded, rather than leaving it up to the user, who is not as well placed to make the decision.

>Problem: > >New users must look for a plugin manager and figure out how to install it. > - Nvim documentation should be able to give a one-liner to install (non-builtin) plugin managers and plugins. > > Lack of a declarative way to specify plugins. > - Lets Nvim reason about dependency ordering / transitivity. > - Lets crawlers build a package index. > - [packspec](https://github.com/neovim/packspec) adds potential to leverage NPM tooling (and possibly infrastructure).

https://github.com/neovim/neovim/issues/20893#issuecomment-1...

I find it weird to not have one, given the ubiquity of plugins in (neo)vim. These editor are self-proclaimed "super easy to extend/program", until now it was awkward to need a third party plugin manager to "extend" them (the vast majority of people use plugins and don't extend all the functionalities with their own code). Plus 0.12 is said to be "The year of Nvim OOTB": https://neovim.io/roadmap/

A neovim plugin manager is essentially a git clone tool that knows how to execute a setup function. This aspect of plugin management is the same for all plugin managers in neovim. The goal is to have something that mostly works as-is but other plugins managers can potentially build off of to support advanced features like lazy loading.

They're trying to improve "setup experience" - see https://m.youtube.com/watch?v=Nq2T28_ILxc (I forget the timestamp and exact phrasing)

Well kickstart.nvim is a template for your own configuration, not a distribution. You're not supposed to update it.

Not sure what you mean by this. Do you mean for versioning requiring `vX.Y.Z` tags? That's quite standard (linux kernel does this). Otherwise it defaults to main/master branch which is also basically standard depending on when the repo was made...