I decided to migrate to zpack.nvim instead. Got to keep my old lazy config with minimal changes, and it works pretty great. I guess I just like the modular nature of my setup, and also I just went through a major rewrite last month, don't wanna redo it just yet.

@codeinabox Just made the change last week! Wasn’t too bad and in a lot of ways it feels simpler. But I am having some trouble with a few custom plugins.

I've been thinking about moving away from nvim-treesitter for this. There seem to be some alternatives already, like tree-sitter-manager. Or I can probably just get it to work without any plugins.

The only thing that I'm worried about are the features provided by nvim-treesitter-textobjects. Has anyone been able to replicate those in native neovim, or even using some other plugin that's not dependent on nvim-treesitter?

Edit: There seems to be some interesting recent development.

The Hacker News thread sided overwhelmingly with the maintainer. Hard to disagree.

Not sure I'd buy that line of thought.

Had the same question, until I've read your comment

For everyone else with the same thought:

Quick context: Neovim 0.12 (released March 29) ships built-in treesitter support, a native plugin manager, and native LSP completion. The nvim-treesitter maintainer had been rewriting the plugin to require 0.12 - and documented this clearly. Users kept demanding backward compat with 0.11. Maintainer burned out and archived it. The Hacker News thread sided overwhelmingly with the maintainer. Hard to disagree.

What happened?

edit: never mind, i should learn to read the fucking article hah

Strongly agree. I switched to helix because of this. It’s sort of like the fish shell in that it “just works” without the need for any plugins.

Just configure your LSPs are you’re rolling.

https://helix-editor.com/

I went back to vim. I use 4 plugins, it is stable and it works everywhere.

I am not playing the version incompatibility game anymore.

I got a plugin that is untouched for 7 years and it still working as intended.

Easy setup, setup once, forget about it.

With neovim, I wanted an editor, I ended with a puzzle.

I’ve grown to like helix as a cli editor because of this. The key map is different enough to be slightly annoying, but it has everything in need with zero configuration - something that took tons of plugins on neovim

as someone who is perpetually an intermediate beginner in all things in the computer science world (even though I have a CS degree):

(And, as a long time vim user who has moderate knowledge on what vim can do for me, and has grown up with ctags, cscope, fzf)

Does anybody else feel like we need to tame the complexity that is neovim configuration? Distros exist but they just package the complexity into sane defaults. Argh! every way of handling this seems boils down to trade-off and preferences if i go down the rabbit hole far enough.

but I feel like there should be a better way to organize this complexity. The other day I gave up trying to understand lua and just asked an LLM to set me up the LSP, tree-sitter, telescope, which-key, and few more plugins.

The most important thing I remember and share was I wanted to make these powerful plugins able to take advantage of each others' expressive behaviors.

One example is LSP operation that has multiple results like "All references to this symbol" can be displayed and moved to with a telescope window, while binding it to ctags like key-binds.

I keep trying to learn lua and lua tables and it just doesn't stick after sometime. Maybe my brain isn't as elastic anymore now that i am above 30 or something.

It’s sad but it is what it is. I wish the author all the best and that they get well soon. But I want to focus on the technical side.

Some tree-sitter functionality and highlighting is already in Neovim. For Lua, even the highlighting groups (@...) are available. So this is mostly fine.

What’s missing for me is a way to get the highlighting groups to other file types, like HTML or JSON, etc. There is some highlighting, so I guess the general parsing from the built-in treesitter is done.

I wonder how we can do this manually either by configuration or using a minimalist plugin.

Same. Recently migrated to it from mini.deps, spent way too much time on it though :) My config: https://github.com/hosaka/nvim

I'm kind of excited for the new built-in packet manager, primarily because its an opportunity to rewrite my config 😋

I’ve been using vi through Neovim since the early 90’s, and I’ve tried the distros; a few anyway: Astro, Lunar, Lazy, Chad. But I always comeback to a bespoke config and am left wondering why people use distros.

They’re good for getting some ideas about what you might be missing, but one’s own config is pretty easy these days. It wasn’t in the vimscript and early packager complexity, but now it is easy.

And with the new vim.pack, even using package managers seems like unnecessary complexity for a little gain in api utility.

Just to add to it, there's a thin wrapper around it called zpack that's basically a drop-in replacement for lazy.

I'm not the dev, but I've migrated from lazy to it without much of a hassle, and the performance seems to be on par. I did encounter a bug, but the dev was quick to fix it. Just wanted to give them a shout-out.

God damn, they're an asshole. Never even heard of them, but that comment was wild and out of left field

Open source developers are lovely people who take tons of free time out of their lives to bring something into the world that everyone can use and benefit from. They are not compensated, and don't owe anyone anything. I will never understand why people come into issues, discussions, etc. demanding things, being rude, and complaining about software they get for free and didn't have to lift a finger for. If you don't like the software they are creating or maintaining, you can fork your own version and spend your free time changing it however you like.

Clason, I doubt you will ever read this, but if you do, there are so many people who love the plugin you've created and use it every day. We really appreciate all the time you've spent giving this gift to all of us for free. I 100% respect your decision to step away (hopefully only temporarily, but also understand if it's permanent). Wishing you all the best, and sorry you had to deal with humans being horrible.

I mean, for good reason.

If I had to deal with shushtain I’d quit too.

Looks like the maintainer burned out. Maybe give them some time to recover.

https://github.com/nvim-treesitter/nvim-treesitter/discussions/8627

@Hexarei @codeinabox I was about to say that. Loading a plugin with it’s default config is easy (shit I did that back with Vim-Plug, while ignoring Packer because "it just works", a couple years ago).

It doesn’t, it shifts responsibility at best.

This reads like AI. But also doesn't touch on the problem of running setup functions and such being very different.

It successfully protects us from authors not including lazy loading, why is that bad?

The Deal-Breaker

vim.pack has no event/filetype/command-based lazy loading. None. You either load at startup or you manually call :packadd in your config yourself.

Oh, so it’s sane and doesn’t try to bullshit it’s way out of plugin authors’ incompetence?

I’m sold!

I haven't looked at the integrated package manager yet so I don't know much about the details. Things like lazy loading is a big deal for some people. I am not sure if and how well that is supported by the native one.