GNU bug report logs - #70408
30.0.50; Eglot and Project integration

Previous Next

Full log

View this message in rfc822 format

From: Ergus <spacibba <at> aol.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>, 70408 <at> debbugs.gnu.org
Subject: bug#70408: 30.0.50; Eglot and Project integration
Date: Tue, 16 Apr 2024 15:03:44 +0200

On Tue, Apr 16, 2024 at 01:33:31PM +0100, João Távora wrote:
>On Tue, Apr 16, 2024 at 12:42 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> I think this discussion should include João, so I added him.
>
>Alright.
>
>More importantly, I think this discussion should include Dmitry, as this seems
>to me a project.el extension.
>
Indeed. Actually Dmitry suggested me to open the bug.

>This discussion should be aware of these half-recent developments
>https://github.com/joaotavora/eglot/discussions/1337
>
I will give it a look.

>In a few words, Eglot user's main gripe with project.el is project.el's
>inability to help the user define or designate subprojects within
>larger projects.
>Eglot has worked around that, and the current work-around is very
>effective (though not really well documented beyond that GitHub discussion
>forum).
>
A bit more details on the workaround and its final state may be useful.


>If Ergus's developments change project.el so that this special Eglot code
>isn't necessary, that's great IMO.  If they make it so that Eglot now has
>to depend on extra package and extra project.el features, that's not so
>great.
>
I would like to avoid inter-dependencies, however, considering that
Eglot and project.el are both in vanilla; maybe we could be a bit
flexible here.

However, I thing that there are some ways to handle that.

So far, what I had in mind was a sort of non-intrusive api (either in
eglot or project.el) that could be used by project.el (and/or a
project.el backend) to provide more accurate information to eglot.

As I said before, the real issue is that project.el is intended to
initialize lazily while eglot is generally already running; so the only
realistic alternatives I see are:

1. Make eglot call a project.el function to detect the build-dir and
compile-commands.json (or equivalent)

2. Make project.el to check if eglot is enabled and call some eglot
function to update the eglot's "build-dir".

From these two I actually prefer the second one because it may happen
that a project has different build-dirs each of them with a different
compile-commands.json (i.e debug and release) and the user wants to
change build-dir dynamically and potentially inform eglot about the
change.

>That's my opinion as current Eglot maintainer.  A capable future
>Eglot maintainer may have another opinion and want to steer ship
>in a completely different direction.  I'm looking for such a person, btw.
>
>João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.