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

["João Távora" <joaotavora@gmail.com>]

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

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

:-)  and the kitchen sink to handle all the quirks...  I Yuri is just
right, there are too many problems in the general case, but in the LSP
case it's more tame, which explains why other editors manage to use
it al all.

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

Or the possibility of it being an '(eval ...)' form.  I think
that should make it 20% (I found a lot of eval when perusing
GitHub for .dir-locals.el examples).

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

Of course not.  Just target the 90% and bail out for the 10%.
Usually, if a user has used dir-locals-set-class-variables,
probably has no trouble with editing dir-locals.

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

I think you misunderstood me.  i was proposing that you work
on that generic variable editing facility, and open up an API
for packages like Eglot to take advantage.  Start working
on it in, say, lisp/files-x.el and then later on we could
consider making it a :core ELPA package.

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

I read your code and I even here I don't agree :-) There are
a couple of '--' references in there, but this is easy to overcome. And
Eglot cannot change that logic without breaking backward compatibility
so you're adhering to a published interface.  So even an
"eglot-edit-wconf" library would make sense as a GNU ELPA package.

João