Provide an installer for language servers

[JLT032]

while in general i'm appreciative of what helix offers, somehow it want to down the same path as other text based editors and became agonising

i understand the community model works well for developers but as a non-developer it feels like being hit with a brick in the face to find how convoluted everything is to set up

i do very much appreciated the ease of use like with hx -g fetch and hx -g build which are to me exemplary, and also hx --health is exemplary

the things get blury real fast

I believe it would be most recommendable to have an hx fetch <language> which could save people from having to find by trial and error vscode-css-language-server and related others no longer exist and are now named vscode-langservers-extracted Somehow

I'd suggest to add a langerepo.toml file to ~/.config/helix/ which is provided by default and to host the source on the wiki so this can be updated by community participants

It is much appreciated to consider and implement such

Thank you

JL

[waddie]

Helix ships with config for 150+ language servers, some of which might offer half a dozen different ways of installing them depending on OS, preferred package manager, etc.

Making hx fetch <lang> do the right thing in all or even most circumstances would represent an enormous maintenance burden.

And hosting that information on a community-edited wiki would be an even bigger security risk. Anyone could change the vscode-langservers-extracted “recipe” to point to malware.

I’m sure there’s plenty of room for improvement in the documentation, but your idea is highly impractical.

[JLT032]

Thanks for you feedback @waddie
I hope this response finds you well.

I'm certain you know how to use Helix way better than I do, at this time I feel like it's just cumbersome to go thru the motions every time to set things up while typically it's already know but not documented.

I'm almost certain the correct URLs for any or all of the language servers mentioned to install and configure manually is known with Helix and/or the Helix community. I trust a versioning system could take care of any of the security risks perceived ?

In fact, this would not be an enormous maintenance burden' but a one time effort with low maintenance effort over time. Unless language server repositories change every week or every month it would become maintainable in short time.

My consideration was also for a single language multiple options could be included as to accommodate variants and such.
The idea to have binaries installed in a folder dedicated or at least visible to Helix so such would 'just work' is appealing, no?

Making use of hx fetch <lang> would actually avoid the hassle of dealing with package managers and OS variations. I'm almost certain most if not all would be accessible making use of for example making use of libcurl ?

If Helix ships with config for 150+ language servers, how does that show ? Why is it required then to download vscode-langservers-extracted and others just to have support for html, css and any other default language? Code completion being hit and miss experience?

Security was a considertion while filing the request. You consider it is not a security risk to have people 'fend for themselves' getting all the languages suppport up and running?

The use of such a registry could in fact reduce the security risk of people sourcing language servers from wherever by pointing to the official repositories instead of some 'drive by download'

Best

JL

[archseer]

I think you underestimate the complexity here. The right install method depends on the user's OS, environment and personal preferences.

For example: Should the server be installed through homebrew? Or your distribution's package manager? Or through npm, is yarn in scope, or bun? Is it a global npm binary or is it version controlled by your project? If you're on nix you probably want to manually install the LSP under your project's flake so it's scoped to that env and versioned separately. And so on. We deliberately avoid this entire can of worms since it's a lot of very brittle boilerplate to maintain.

The user taking a minute to read the wiki and making a conscious decision on what to install is the secure option rather than us dropping random binaries onto your system.

[drocha87]

The idea is interesting, but please keep Helix simple. Even when working with several languages, installing the required language servers yourself is not particularly difficult. You can also keep a small script in your personal configuration to install and update the language servers you use.

A big part of Helix’s appeal, at least for me, is its simplicity. My configuration is minimal: I change the theme, make Esc collapse the selection, and adjust a few small preferences. Adding a dedicated package manager for language servers feels like unnecessary complexity and another subsystem the Helix team would have to maintain.

[eminence]

The helix community already does a nice job with documenting how to install language servers. For example: https://github.com/helix-editor/helix/wiki/Language-Server-Configurations#bash-language-server

I have two language servers that I can pick from, quick 1-line things I can paste into my terminal to install them (assuming I trust them), and an direct link to the relevant project web pages to learn more.