[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Considerations for adding additional default LSP-servers to eglot
From: |
Philip Kaludercic |
Subject: |
Re: Considerations for adding additional default LSP-servers to eglot |
Date: |
Wed, 29 Jan 2025 10:23:44 +0000 |
Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> Hey everyone.
>
> I think adding eglot/LSP to emacs has been one of the most powerful and
> transformative changes for OOB usefulness when using Emacs for programming.
>
> LSP has clearly been a popular protocol and almost all languages worth
> mentioning has a LSP server now. The current list of LSP servers maintained
> in eglot is already impressive, but I find myself needing to augment it with
> servers not yet included.
>
> Common for those that are included is that they are installed on the system
> path, and can be invoked directly from Emacs without any complicated
> arguments, or needing to resolve the path of the language server itself.
>
> Common for those I have augmented the list with is the opposite: They are not
> typically installable in a regular single-tool, single-path like matter. They
> often require complicated arguments.
>
> The way I usually install them is by installing VSCode, installing the
> relevant extensions there (which bundles the LSP servers), and then reuse
> those LSP servers from Emacs.
>
> Entries for these servers typically look like those below:
>
> (powershell-mode . ("pwsh"
> "-OutputFormat" "Text"
> "-File"
> ,(car (file-expand-wildcards
> (substitute-in-file-name
>
> "$HOME/.vscode/extensions/ms-vscode.powershell-*/modules/PowerShellEditorServices/Start-EditorServices.ps1")))
Even if we wanted to do this (which seems unlikely considering that it
is very unemacs-y to just download executable from the net, even if some
other tool is doing that for us), this wouldn't be a robust/portable
approach. IIRC windows doesn't store stuff like this in their home
directory and on GNU/Linux systems, one might install vscode using
Flatpak or some other tool that places the files elsewhere.
I could imagine a package on ELPA that supplements `eglot--lookup-mode'
by looking for executable in some additional, well-known places, or at
least explicitly prompts the user to download some servers, but I feel
that hard-coding this in eglot would be the wrong approach.
(Also, I think I mentioned this before, but I would like to see major
modes customising `eglot-server-programs', just like they modify
`auto-mode-alist', seeing as the people who use and develop the major
mode are probably in the best position to test and evaluate the
performance of a LSP server. This presumes that the
`eglot-server-programs' interface is stable, which I understand that it
has now become?)
> "-Stdio"
> "-HostVersion" "1.0"
> "-HostName" "Emacs"
> "-HostProfileId" "Emacs.Eglot"
> "-SessionDetailsPath" "/tmp/emacs"
> "-BundledModulesPath"
> ,(car (file-expand-wildcards
> (substitute-in-file-name
>
> "$HOME/.vscode/extensions/ms-vscode.powershell-*/modules")))
> ))
> (bicep-ts-mode . ("dotnet"
> ,(car (file-expand-wildcards
> (substitute-in-file-name
>
> "$HOME/.vscode/extensions/ms-azuretools.vscode-bicep-*/bicepLanguageServer/Bicep.LangServer.dll")))
> ))
>
>
> My question is:
>
> Would entries like this be accepted as patches in mainline Emacs? Or would
> the fact that they depend on other external software to be installed make it
> a no go?
>
>
> --
> Kind regards
> Jostein Kjønigsen
>
> jostein@kjonigsen.net 🍵 jostein@gmail.com
> https://jostein.kjønigsen.no