Re: Explain a bit more on how to configure language server in Eglot's manual

[João Távora]

On Wed, Mar 8, 2023 at 3:01 PM Augusto Stoffel <arstoffel@gmail.com> wrote:

> > I don't understand: didn't you state you _like_ dotted notation?
>
> Yes, as a quick fix.  But you and the circumstances showed that it isn't
> nearly good enough.

OK.  Then we'll hold that idea back.  AFAICT, Yuan also is also a fan
of that notation, so maybe he can chime in.

> > A special plist editing mode for a single Eglot variable falls into
> > that category, IMNSHO.
>
> By the way, my suggestion is to edit a JSON value, which is what the
> server receives, you can copy and paste from other places, and doesn't
> require you to know jsonrpc.el internals such as :json-false and the
> translation of nil.

They are not internals.  They are the external, published and documented
way to create JSON for jsonrpc.el contexts.  The documentation isn't
great, I know.  This is precisely what this thread is originally about
and I'm working on it.

> > and I don't see any other good place to put a single utility function
> > that facilitates it but in Eglot.
>
> The utility function belongs to map.el.  It is called `assoc-in` in
> Clojure.

Yuri presented some pretty good arguments about how that would
be a bad idea.  Also, not a Clojure expert, but AFAIK that
function doesn't take dotted notation strings as input.

> Speaking of bloat, and I know I shouldn't insist, but a basic version of
> the savable eglot-show-workspace-configuration barely adds 30 LOC.

Your code has at least two big problems:

* it takes the current value from one place and
  potentially saves it in another place.  This is asking
  for trouble.  I know you favour the 'nil' method exclusively
  for setting e-w-configuration, but it's not the only supported
  methods and there are configurations out in the wild that
  we can't break. Also note the that per-file or per-sub-hierarchy
  workspace configurations _are_supported by LSP (the scopeUri
  argument to the workspace/configuration server request).

* it doesn't take into account dir-local-set-class-variables

These are exactly the type of edge cases that I don't want
to handle in Eglot.  In other words, Emacs has many variable
setting methods and making an Eglot function to oversimplify
them, even if it happens to work for an estimated majority of
cases, is a bad idea, simply because it will break a minority.

That said, your code has great ergonomics and you seem to be
a very able Elisper.  So I'll restate: if a generic, safe
version of this hits Emacs libraries, Eglot will be happy to
use it and I at least will be very grateful for that contribution.

A better dir-local editing facility would account for (at least)
those two cases.  Even if that accounting is, at first, just bailing
out and warning the user if it detects them.  That's perfectly fine
in my book.  It'll mean the code will work fine for the 90% of users
and not confuse the other 10% to death.

That new dir-local editing facility could even allow you to
use JSON notation to edit a variable's plist, and eglot.el could
hint on that preference by setting 'serializer' and 'deserializer'
properties on e-w-configuration (though a more lispy name would
be 'write' and 'read' perhaps).

Additionally, in eglot.el, a variable watcher could be added to
e-w-c to take care of LSP signalling automatically if changes to
the value are detected.

So I urge you to generalize your code and propose it here
in a new :core ELPA package.

Thanks,
João