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

[Augusto Stoffel <arstoffel@gmail.com>]

On Wed,  8 Mar 2023 at 19:43, João Távora wrote:

>> 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.

Of course you would need to combine it with split-string (and a
dolist or seq-reduce to process a list of those dotted names).

>> 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).

Right, this is a problem.  It's missing the part that will “not confuse
the other 10% [of users] to death”, as you said.

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

This too.  Neither the possibility of e-w-c being a function.

> 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.

Fair enough, but it seems that this multiplicity of methods basically
precludes one from making a helper tool for configurations.

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

If you provide a function that receives a new configuration value and
stores it back in the right place, then this package becomes trivial.
If you don't, then this package is completely entangled with Eglot's
logic for reading configs.  In either case this doesn't seem to make a
lot of sense as a separate package.