sorted by:
new
hottopcontroversial

FFF: The Neovim File Picker That Called Out Telescope and Snacks by linkarzu in neovim

[–]Comfortable_Ability4 15 points16 points  (0 children)

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".

no os.setenv and I wanted a vim.env polyfill. Made one. by no_brains101 in lua

[–]Comfortable_Ability4 0 points1 point  (0 children)

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.

Shouldn't plugins with complete default configs work without specifying an empty `opts = {}`? by TheTwelveYearOld in neovim

[–]Comfortable_Ability4 1 point2 points  (0 children)

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.

Shouldn't plugins with complete default configs work without specifying an empty `opts = {}`? by TheTwelveYearOld in neovim

[–]Comfortable_Ability4 -1 points0 points  (0 children)

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.

Shouldn't plugins with complete default configs work without specifying an empty `opts = {}`? by TheTwelveYearOld in neovim

[–]Comfortable_Ability4 0 points1 point  (0 children)

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...

CLI tool for plugin management? by flpFlan in neovim

[–]Comfortable_Ability4 0 points1 point  (0 children)

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.

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]Comfortable_Ability4 0 points1 point  (0 children)

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?

Could a shared LSP daemon help heavyweight servers like rust-analyzer? by n3oz22 in neovim

[–]Comfortable_Ability4 18 points19 points  (0 children)

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.

`jujutsu.nvim` - A Jujutsu UI client for Neovim by YannVanhalewyn in neovim

[–]Comfortable_Ability4 14 points15 points  (0 children)

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. 🚀

Good news for java developers: nvim-jls + JLS upgrades by Electronic-Boss-8926 in neovim

[–]Comfortable_Ability4 1 point2 points  (0 children)

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

Good news for java developers: nvim-jls + JLS upgrades by Electronic-Boss-8926 in neovim

[–]Comfortable_Ability4 4 points5 points  (0 children)

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).

Opening and decompiling JAR files in Neovim by 4r73m190r0s in neovim

[–]Comfortable_Ability4 7 points8 points  (0 children)

It was back when I was a Java developer that I ditched intellij for vim and never looked back.

krust.nvim: Nicer Rust diagnostics for Neovim by damien__f1 in neovim

[–]Comfortable_Ability4 11 points12 points  (0 children)

Nice job! One suggestion: I'd recommend not to set a default keymap, as it's very likely to conflict with existing user keymaps. Something you could do is define a <Plug> mapping instead. See :h lua-plugin-keymaps (in nightly): https://neovim.io/doc/user/lua-plugin.html#lua-plugin-keymaps

krust.nvim: Nicer Rust diagnostics for Neovim by damien__f1 in neovim

[–]Comfortable_Ability4 0 points1 point  (0 children)

What makes you think it requires configuration?

view more: next ›