bug#73280: 30.0.90; Eglot: eglot-workspace-configuration might not be found in .dir-locals.el

[Troy Brown <brownts@troybrown.dev>]

On Mon, Sep 16, 2024 at 9:48 AM João Távora <joaotavora@gmail.com> wrote:
>
> On Mon, Sep 16, 2024 at 12:38 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > João and Stefan, any comments?
> >
> > FWIW, I'd rather think this is a feature, since users don't need
> > separate Eglot settings for ada-mode and ada-ts-mode.  But maybe I'm
> > missing something.
>
> You didn't miss that much.  This is half-feature, half
> headache-I-didn't-want-to-worry-about. So I put int the 'car'
> on purpose.  The first of the modes listed in a e-s-programs entry
> is usually the most representative one of the language, more or less.
>
> Is there a downside to mentioning a major mode you don't
> actually use in your .dir-locals.el, Troy?
>

I would say the major downside is that it is not intuitive at all.
It's not consistent with how directory-local variables behave.  When I
saw that the variable was set locally in my buffer but that the
configuration wasn't actually applied to the server, I had to dig into
this and understand what was going on.  I have to imagine anyone else
using this would be just as stumped as I was when it wasn't working.

I don't think I'd agree with the first mode being representative, it
seems somewhat arbitrary.  For instance, in order to change
eglot-workspace-configuration for "sh-mode", you have to set the
configuration in .dir-locals.el for "bash-ts-mode"...who would've
guessed this?  Just looking through the lists of modes corresponding
to the same server, I don't think people would normally make this
connection, and the fact that it doesn't work the same way that
directory-local variables do, makes it even more unexpected and
confusing.

What about having eglot--workspace-configuration-plist cycle through
the list of modes for the server until it finds a non-nil
eglot-workspace-configuration, or has scanned them all?  This would
seem like a better approach since it will at least find a
configuration if one exists, rather than ignoring an existing
configuration.  I don't know if that would be considered too CPU
intensive or not.  It's still not the same behavior as a directory
local variable, but I think it would be an improvement over the
current behavior.