Re: User experience: eglot configuration

[JD Smith]

On Jan 29, 2025, at 1:47 AM, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> wrote:

Hi,

knowing there are much more pressing issues, I nevertheless would like to spend a couple of cycles rewording a reflection of mine from the past:

There are lots of LSPs around with adequate Web pages. 

Most include configuration examples for various editors/IDEs. 

How many include a configuration example for Emacs?

Eglot does have the ability to set eglot-workspace-configuration to a function, which provides tremendous flexibility in configuring multiple different servers based on project, file path, host, or any other criteria.  This is a real time saver vs. maintaining server-specific config files in each project.

But it is challenging to configure, for sure.  Every server has its own specific configuration hierarchy.

I'm agnostics on whether JSON or LISP would be a preferred syntax, but there are also some oddities in eglot's workspace implementation that make it very challenging to arrive at a valid config.  For example, to configure pyright's "stubPath" setting, you note from its docs the following setting:

python.analysis.stubPath [path]: Path to directory containing custom type stub files.

It takes substantial trial and error to determine that this needs to be rendered into eglot's plist syntax as:

(list :python.analysis ; N.B. eglot does not consider :settings nested!

      (list :stubPath

   (expand-file-name "~/some/code/path")))

and not, as you'd expect:

'(:python (:analysis (:stubPath "...")))

I.e. it requires an arbitrary break in the nesting hierarchy from JSON -> eglot plists.  Basically no one can stumble on this themselves starting from the pyright+eglot docs. Maybe it's a bug, or maybe it's specific to this language server.  But surely some fraction of users encounter this and just walk away. 

Perhaps what's needed is one layer of abstraction above eglot-workspace-configuration, aimed at major-mode authors, so they can provide "common settings" for various popular servers in a convenient place.  Users can of the mode can then simply select/configure the desired settings (e.g. with Customize).  Under the hood, this would map onto an eglot-workspace-configuration function which would do the necessary translations for sending the desired configuration over the wire.  Ideally this would be in the form of a simple API would could be used in your own workspace-configuration function, for advanced users who want to "graduate" to that.