emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]