GNU bug report logs - #65418
29.1; Eglot: support clangd inactiveRegions extension

Previous Next

Full log

Message #17 received at 65418 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Filippo Argiolas <filippo.argiolas <at> gmail.com>
Cc: 65418 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Felician Nemeth <felician.nemeth <at> gmail.com>
Subject: Re: bug#65418: 29.1; Eglot: support clangd inactiveRegions extension
Date: Tue, 22 Aug 2023 09:56:24 +0100

[Message part 1 (text/plain, inline)]

On Tue, Aug 22, 2023, 08:09 Filippo Argiolas <filippo.argiolas <at> gmail.com>
wrote:

> In the past, João wasn't keen on supporting non-standard features in
> > Eglot.  I Cc'd him anyway as he is the maintainer of Eglot.
>

Right, but I'm not for making it hard either. Although this is
non-standard, it's similar to a bunch of "code-painting" situations, some
of which are standard, and some of which, like inlay hints are already in
Eglot.

So it shouldn't be a problem in itself to supply support for this in
c-ts-mode or some eglot-c-extra.el or, if done well enough, even an example
snippet of how to support a typical extension in your .emacs.

I'm more worried that this isn't even out yet. Afaik Filippo you compiled a
Clangd 17 with a patch, right? I have done that in the past, but it's not
very practical every time, so either we wait for this to stabilize or you
have to tell me where to grab the patched Clangd and llvm toolchain
somewhere.

Also I'm not 100% happy with my inlay hints implementation based on jit
font lock, which misses the mark more often than I wished. I had an
earlier, less efficient (but afair more correct) implementation before Eli
suggested this one. The fault is not 100% on Emacs side though, and the LSP
spec itself leaves much to be desired regarding invalidating regions. This
is an opportunity to revisit these matters.

Also this IMHO would solve quite an important problem with C
> development, not sure if it's worth waiting while we could solve it
> now with the extension and move to the standard protocol if and once
> the LSP spec will support this.
>

I'm also personally interested in this feature. But how likely is it that
this makes it into the LSP standard, in your opinion?

FWIW, other languages have similar features. Common Lisp has read-time
conditionals for example, which are similar if not identical in function
(and obviously not as rotten as C macros).

By the way, if you didn't know this silly trick, if you're in a #ifdef web,
a half-decent way to know whether a given point is active is to try and
find a definition inside it or type some syntactically correct code. If
Eglot jumps to target or highlights variable names, the region is active,
else it probably isn't.

No idea how easy that would be and if that makes sense but we could
> maybe follow the eglot philosophy of working with existing components
> and just forward inactive regions to hide-ifdef-mode?
>

Yes, that is the philosophy, but these "standard components" differ in
quality immensely. So it's on a case-by-case.

João

[Message part 2 (text/html, inline)]

Previous Next

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