bug#70408: 30.0.50; Eglot and Project integration

[Ergus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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