null-ls.nvim has been archived

[vollowx]

See this issue

[CharlesChiuGit]

maybe we should roll back to efm? or wait for the fork?

[Jint-lzxy]

IMO we can wait for a while to see if there's any progress

[Jint-lzxy]

Several interesting points on moving forward & possible perplexity: https://youtu.be/oy_-hQdkoXg.

[CharlesChiuGit]

Several interesting points on moving forward & possible perplexity: https://youtu.be/oy_-hQdkoXg.

I just saw this last night lol.

[ayamir]

Don't be hurry, waiting a better fork/successor for a while. Of course, we can also rollback to efm.

[CharlesChiuGit]

https://www.reddit.com/r/neovim/comments/150t159/null_ls_alternatives_solutions

[Rinyaresu]

https://github.com/nvimdev/guard.nvim 👀

[CharlesChiuGit]

nvimdev/guard.nvim 👀

I'm also looking the status of the plugin closely, since it's by glepnir.

[aarnphm]

unpopular opinion: glepnir plugin moves faster than the speed of light, which makes living on the edge nice, with a huge burden to always try to keep up with every plugin changes 😄

[ayamir]

https://github.com/stevearc/conform.nvim

[vollowx]

The most acceptable way for myself.

[aarnphm]

stevearc/conform.nvim

From a quick look at the library, it seems like they have yet to have support for lazy initialisation. So this probably will need to couple with LSP config 🤔

[vollowx]

Also, you may use nvimtools/none-ls.nvim as a successor.

[CharlesChiuGit]

https://www.reddit.com/r/neovim/comments/1865vvi/formatternvim_or_conformnvim/

[Mythos-404]

https://www.reddit.com/r/neovim/comments/1865vvi/formatternvim_or_conformnvim/

After I replaced null-ls with conform.nvim I found that conform.nvim has these advantages over

1. startup speed improvement
2. performance improvement when formatting
3. formatting without breaking code folding
4. the ability to specify a range of formatting

[Jint-lzxy]

IMO maybe we could consider splitting the functionalities provided by null-ls (or none-ls as it's now called) between two separate implementations (like conform.nvim + efm-langserver). As @CharlesChiuGit pointed out here, code formatting is just one aspect of what null-ls offers - it's more like a general-purpose language server, with features like code actions, linting, and more. But considering not every workflow uses functionalities other than code formatting, we could make efm an optional plugin (kinda like settings.use_copilot). I can try to implement this when I have some free time and see how it goes lol

[aarnphm]

I think the "correct" way to do this is

• lsp stays as it is, since it is supported from neovim
• linting should be separated outside (maybe to use something like nvim-lint) to avoid the pitfall of null-ls
• formatter should also split out. if needed we can support multiple backends (conform.nvm, efm-langserver, etc.)

For code actions, I feel like it should depends on language-specific. For example, typescript plugins (don't really remember what the specific name is) does have Codeaction, so does rust-tools, clang_extensions.

For all of the things that is not supported by default editors, I feel like we shouldn't do anything more. (my philosophy with editor is sometimes less is more)

[vollowx]

@aarnphm agree, some LSP servers has their own formatting features which are called by vim.lsp.buf.format, and I don't think these features should be mixed up and implemented by one plugin.

[aarnphm]

@aarnphm agree, some LSP servers has their own formatting features which are called by vim.lsp.buf.format, and I don't think these features should be mixed up and implemented by one plugin.

Ye the users responsibility is to call vim.lsp.buf.format, and that's what conform.nvim did . well additionally with the rangeFormatting support, but nothing other than just lsp functions.