Subject: Re: bug#65418: 29.1; Eglot: support clangd inactiveRegions extension

From: João Távora <[email-masked]>
Date: Tue, 22 Aug 2023 09:56:24 +0100

On Tue, Aug 22, 2023, 08:09 Filippo Argiolas <[email-masked]>
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