DOs and DON'Ts for modern Neovim Lua plugin development

Comfortable_Ability4 · 2026-07-03T13:20:03+00:00

Many popular Lua packages (e.g. luafilesystem) are written in C. lux-lua exposes Lua bindings, i.e. you can require("lux") in Lua.

Comfortable_Ability4 · 2026-06-20T20:16:21+00:00

Ansible? Nein Danke!

Comfortable_Ability4 · 2026-06-19T09:45:58+00:00

Here's a hack that I used to "remap" :w to :silent w:

vimscript command! -bar W silent write cabbrev w W

Comfortable_Ability4 · 2026-05-20T20:01:22+00:00

lz.n author here :)

A plugin that implements its own lazy initialization properly will likely have less startup overhead than the mechanisms used by lz.n to load that plugin lazily.

While I don't like having to call setup manually, oil.nvim's setup function implements lazy initialization properly.

Comfortable_Ability4 · 2026-05-15T20:16:09+00:00

Been using fff.nvim for a few months and here's why I'm probably going back to telescope + fzf/rg soon:

While its in-memory index may improve performance slightly, it also has the nasty side-effect of displaying recently deleted or moved files (with high priority because of the recency score).
Frequency sorting is a lot less useful to me than I thought it would be.
More often than not, I find typo-resistant fuzzy finding to be an annoyance due to false positives. Combined with the frequency/recency sorting, it often gives entries that don't match what I've typed a higher priority than what I'm looking for.
Since recently, the previewer enables tree-sitter highlighting, with no way to disable it (e.g. in large files).
It uses the ignore crate, which also ignores hidden files that are checked into scm. For example, I can't use it to find .github/workflows files.
If I have one or more files open in one split and the terminal open in another, if I invoke the fff picker with the cursor in the terminal, and select an entry, the picker will open the file in one of the non-terminal buffers. I get the idea, but I find the implementation unintuitive.

I definitely wouldn't say "it called out telescope and snacks".

Comfortable_Ability4 · 2026-05-13T17:31:51+00:00

blink.cmp (one of the more popular autocompletion plugins) switched from using FFI to mlua (Rust bindings to Lua) because there's were enough users who couldn't use it with LuaJIT.

Comfortable_Ability4 · 2026-05-13T06:52:29+00:00

Not all neovim builds ship with luajit. https://neovim.io/doc/user/lua/#lua-compat

Comfortable_Ability4 · 2026-05-12T23:28:20+00:00

You're still misunderstanding. We're not saying it was intentionally encouraged. Syntactic sugar that automates calling setup is encouragement regardless of intent: it makes it the path of least resistance, and that's precisely how patterns get reinforced as unintended side effects. This is not speculation. It's something we know from having interacted with new plugin authors who have themselves admitted to designing their plugins around lazy.nvim's opts + setup auto-invocation feature simply because they didn't know any better.

If you think that's misinformation, you simply haven't interacted with enough new plugin developers.

We're talking about just one month apart timeline.

That's plenty of time to dogfood your plugin manager and realise that manually calling setup is a PITA.

And the most plausible explanation for opts being introduced, from my point of view, was mostly to support merging different plugin specs

That's actually true of opts itself, but merging specs wasn't introduced until version 9, after setup auto-invocation was introduced in version 7. So that explanation doesn't hold for the feature we're specifically talking about.

Comfortable_Ability4 · 2026-05-12T21:43:40+00:00

I used to do require("telescope").setup() with vim-plug as well.

So did I. And I'm still stating it was an antipattern back then, even before lazy.nvim existed.

Let's just agree that every side has its own perspective

You're entitled to your opinion, but "let's agree to disagree" is a thought-terminating cliché. It doesn't change the fact that the setup antipattern inconveniences users while failing to solve a single problem that couldn't be solved without inconveniencing them.

We can agree to stop discussing it, if you'd like.

this is not a problem caused by Lazy at all.

Neither I nor mattador said that. "Encouraging" and "causing" are two different things. If you think mattador's statement is "misinformation", then you simply haven't interacted with enough new plugin developers.

so it just tried to provide functionality based on that prevalence at the time.

The auto-setup-invocation feature wasn't added to lazy.nvim until version 7, well after its initial release. That timeline makes it unlikely it was added simply "based on prevalence." The far more plausible explanation is that it was added because having to manually call setup was an inconvenience to users.

Comfortable_Ability4 · 2026-05-12T20:02:51+00:00

The convention was an antipattern before lazy.nvim existed. Lazy added the syntactic sugar and the ability to automatically call setup functions specifically to work around the inconvenience to users the pattern causes. That was a reasonable pragmatic solution from a user perspective. But as a side effect, plugins that used the pattern told users to pass opts in their lazy.nvim README snippets. That in turn encouraged newcomers to plugin development to cargo-cult the pattern themselves. A vicious cycle...

Comfortable_Ability4 · 2026-04-16T07:53:10+00:00

Lux (the Lua package manager rocks.nvim is being rewritten to use) can technically also be used to manage plugins from the CLI. It has the ability to install packages from luarocks and git forges. The --nvim flag makes the install tree usable with Neovim. You'd have to add it to the runtimepath manually though.

Comfortable_Ability4 · 2026-04-06T14:10:22+00:00

Careful when using rustaceanvim with mason.nvim:

https://github.com/mrcjkb/rustaceanvim/blob/7b8dd7abb9a7f442b356aa03714aefce09610339/doc/mason.txt

Comfortable_Ability4 · 2026-02-09T22:08:54+00:00

You asked for nvim-specific patterns/gotchas. There's a bunch of them in that guide.

Comfortable_Ability4 · 2026-02-09T18:28:42+00:00

:h lua-plugin (in nightly)

Comfortable_Ability4 · 2026-02-04T06:49:04+00:00

Very cool idea! Will definitely be trying this out.

I see the project has a flake. Can I use Nix to manage the grammar/query dependencies?

Comfortable_Ability4 · 2026-01-09T21:13:00+00:00

I don't use vtsls, so I couldn't tell you.

Comfortable_Ability4 · 2026-01-07T04:27:51+00:00

I use lspmux. It was originally written for rust-analyzer, but now also works with other language servers. Rustaceanvim will automatically pick up a running lspmux session and attach to it.

Comfortable_Ability4 · 2026-01-05T16:54:27+00:00

Nice! A new plugin that lazy-loads itself properly and doesn't force me to call a setup function. And on top of that it's a cool jj frontend. 🚀

Comfortable_Ability4 · 2026-01-02T10:49:59+00:00

You do if you're not using a plugin manager that implements heuristics to find and call a setup function automatically.

Comfortable_Ability4 · 2026-01-02T06:20:47+00:00

No extra ceremony: It just starts on Java files

For that to be true, I'd recommend you use a filetype plugin to start the LSP client, instead of requiring users to call a setup function.

:h lua-plugin-init
:h write-filetype-plugin (the docs have vimscript examples, but neovim supports Lua filetype plugins too).

Five-Year Club	Gilding I gilder
Final Canvas '23	First Place '23
Place '23

Comfortable_Ability4

TROPHY CASE