GNU bug report logs -
#73280
30.0.90; Eglot: eglot-workspace-configuration might not be found in .dir-locals.el
Previous Next
Full log
Message #14 received at 73280 <at> debbugs.gnu.org (full text, mbox):
On Mon, Sep 16, 2024 at 9:48 AM João Távora <joaotavora <at> gmail.com> wrote:
>
> On Mon, Sep 16, 2024 at 12:38 PM Eli Zaretskii <eliz <at> 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.
This bug report was last modified 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.