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 23:51:21 +0200

On Tue, Apr 16, 2024 at 09:30:20PM +0100, João Távora wrote:
>On Tue, Apr 16, 2024 at 5:02 PM Ergus <spacibba <at> aol.com> wrote:
>
>> project-multi--merge-plist is just a hack function to merge the
>> eglot-workspace-configuration value without overriding the existing
>> sub-values if already set (in case the user sets some sub-values in the
>> dir locals then those takes precedence)
>>
>> Then this restarts eglot
>>
>> IIUC this is equivalent to call `--compile-commands-dir=build` and at
>> the moment is working for me.
>
>This seems extremely complicated, but happy it works for you.
>
The core idea is actually very simple: if project.el detects a
build-dir with compile-commands.json inside then update
eglot-workspace-configuration. The rest is just the api to set directory
local vars (extremely complicated indeed, but that's what it is)

>If during an eglot session something happens that leads to want to update
>the "workspace configuration" for a given session, you can set it and
>then call `eglot-signal-didChangeConfiguration` which is part of Eglot's
>API. No need to restart.  Also note that eglot-workspace-configuration
>can be a function, maybe that's useful to you somehow.
>
This is actually very useful; it is probably the only feature I needed
in the eglot side.

>> At the moment I assume the outer most only; which is the simpler one to
>> setup and implement woth the current project.el support. The main goal I
>> have is OOSC, not nested projects.
>
>OK.  I don't know what OOSC is but if it's somehow related to "out of tree
>builds" 
Out Of Sources Compilation

>I think these are fine, but builds aren't normally not part of a project:
>my
>.gitignore files ignores them.
>
Indeed, but my function in project.el won't.

The code I wrote considers some file-names as root hints (i.e
CMakeLists.txt) and others as build dirs hints (i.e CMakeCache.txt).

My project-find-functions hook searches upwards in the directory trees
for a root hint and in the top most root it searches not recursively for
the build dir hint in the root's sub-directories.

When there are multiple build dirs it asks to the user for which one to
use.

And after that it searches for the compile-commands.json there.

The code also sets a directory-local-var to avoid repeating this search
for all the other files in the future; because I use Tramp extensively
and such searches may slow.

>João

Previous Next

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