Language Module Redesign (feedback requested)

[NotAShelf]

Good day nvf users, as most of you are aware the language module refactor has been on our to-do list for a while now. It has been postponed due to several internal changes that managed to take priority, but now it is back as our main priority. Especially with several language incoming additions.

The Problem

A lot of technical debt has accumulated around the language module. Some of the changes made has sacrificed on the customizability of the module, and as new language modules are requested/contributed the debt only grows larger. Before this becomes fully unmanagable, I would like to refactor the language modules in full.

The Solution

The module options set internally, and obscurely, by vim.languages.* must be moved to an user-facing interface. nvim-lint and conform have already made their ways into vim.diagnostics and vim.formatter so that is a good step over null-ls, which did not expose anything other than a configuration option to dump strings into. Additionally, we're in the process of exposing language server options as lsp.options with #643, and that'll allow a larger degree of customizability.

Yet, one problem remains in PRs such as #575; some languages require using multiple LSPs (hint python hint) and others barely have a single functional LSP. Allowing multiple LSPs in one module but not in another opens the door to a large inconsistency. To help counter this, I am proposing vim.lsp as an option that offers full control over LSP setups directly outside the language module, which should allow configuring LSPs, diagnostics and formatters separately as a partial remedy to #747.

Discussion

I would like your feedback on the matter. Feel free to leave any questions, comments, suggestions, proposals, etc. below this post and we'll discuss them in detail. nvf is shaped mainly by feedback and as such your feedback is important to us.

[rice-cracker-dev]

It's been bugging me for a while that we can only choose one formatter at a time, some projects use prettier and some use biome. Maybe we could allow for multiple formatter and activate them if the configuration file is present in the root directory?

[horriblename]

this would work nicely once conform lands. Conform allows supplying custom conditions.

[TheColorman]

To me, one fo the most attractive parts of nvf (and one that also impresses those that I show my nvf config) is the ability to enable full language support, including parsing, debugging, linting and lsp, with a single languages.<lang>.enable. It almost feels magical.

That said, I definitely see the benefits in moving language configuration out of the individual language options. The language framework is pretty rigid, and the nvim-lint and conform modules definitely allow for more freedom for end users, as well as more consistency.

So while I think the direction is positive, I hope there'll still be room for some automagic language configuration. As an end user, I also find it intuitive to have language-specific tooling under their related language, though this is partly because I started using Nix before Neovim, and so have never written a full Neovim configuration in lua.

Perhaps options under each language that proxy to e.g. vim.lsp with some defaults, but a more consistent structure across languages to prevent techincal debt? I haven't gotten familiar with the nvf codebase, so I'm not sure how realistic any of this is.

[NotAShelf]

I have no intention to remove automagic options. vim.languages is no doubt one of the biggest strengths of nvf, and I have no intention to remove it. That said, I find the lack of a lower-level API (to configure individual components, without having to rely on language modules, to be a weakness in contrast. What if you just want to configure a LSP without any of the crust?

That is why I would like an alternative (but not a replacement) to the high-level options. vim.lsp (as we have decided on the name) will allow configuring LSP servers directly, and vim.languages will wrap it as we did for null-ls previously.

tl;dr: all of the language modules are staying. They'll take some time to update to the new API, but they'll stay nevertheless.

[skttlock]

Hello and thank you for your work,

My main gripe, more molehill than mountain, with nvf is the lack of repl support and missing some languages I'd like to learn (namely, a Lisp like Janet or something). I'm working to add vim.repl to enable this through conjure.nvim. I'm also thinking of packaging vim-sexp into vim.util. I admit I've been focused on doing this through contribution to the project rather than the custom plugin method described in the docs, maybe I'll take another look at that.

My question is so: in light of this discussion, how should one add support for another vim.language? Just use the current languages as an example and rework later to match the redesign? Would it be possible to provide an "empty" version of a language module, old or new?

[horriblename]

if you're planning to add an unsupported language, and don't intend (at least for now) to add LSP support, you won't get much conflicts. That said, the feature freeze for languages is still in place so we won't merge it anytime soon

[NotAShelf]

Hi all, #860 has been isolated as a separate patch and merged into main. With above needs in mind, I would appreciate your feedback if you get a chance to test it out.

[rice-cracker-dev]

Since languages like JS/TS, Astro, Svelte etc often shares the same linter and formatter (eg: eslint, prettier, ...), we could have linters and formatters be their own separate modules (eg: vim.formatters.prettier) similar to how the language modules work, and the language modules itself can just enable those modules instead of having to paste the same code for every languages.

[NotAShelf]

That would create a weird scoping issue. Not a bad idea, but worth considering through and through.

vim.<category>.<plugin (if applicable)> is the current layout I'm trying to go for, byt maybe we can do like vim.formatters.preConfigured and then "preConfigured" (or whatever the name we give it) would replace plugin in the scope.

I have been thinking about getting rid of categories entirely. As previously expressed by contrubutors (a lá @horriblename and @diniamo), they complicate the tree (especially the nested categories),which is why I am considering a major refactor (possibly in 1.0 or 0.10.or whatever) to basically move to /modules/<plugin>/plugin.nix for everything.

[horriblename]

I like the idea, tho we should hold this off till after the language module rework

[diniamo]

What scoping issue? Besides, I don't see any other way to fix the issue OP mentioned (same tooling for different language modules). Maybe doing common options in a separate file, and importing that? However that means unnecessary eval, if multiple of those languages are enabled.

And yeah, I would have preferred a flat vim.plugins layout to categories.

[NotAShelf]

The module scope (as in naming, not access) is meant to be logical and intuitive, deriving from the existing scope is bad UX. If we are introducing such a change, I think the naming and structure should change first.