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

["João Távora" <joaotavora@gmail.com>]

Filippo Argiolas <filippo.argiolas@gmail.com> writes:

> On Fri, Aug 25, 2023 at 2:16 PM João Távora <joaotavora@gmail.com> wrote:
>>
>> Filippo Argiolas <filippo.argiolas@gmail.com> writes:
>>
>> OK, after fetching that git snapshot today, I've done this:
>>
>> It's bare-bone but it works, because the method for communicating
>> "inactive regions" is very basic (and similar to unsolicited
>> diagnostics).
>>
>> Only minimally tested, so YMMV.
>>
>> This serves as a good example of how to support unofficial LSP
>> extensions using Eglot as an API.  Could well be in the manual.
>>
>> The method for providing a client-side capability based on a server is
>> crude.  Servers do identify themselves properly via LSP, but only after
>> being initialized, so it's too late and I had to use an heuritic based
>> on the command.  We could also use a proper subclass for clangd servers,
>> but that's too verbose and overkill IMHO.
>
> That's great! Definitely owe you a beer or a bottle of your favorite
> beverage!

Glad to help.  You're lucky I'm not some kind of wine connoisseur ;-)

> About the heuristic would it be that bad to just include
> inactiveRegions in the general client capabilities? Guess it would be
> just ignored by other servers not supporting it, wouldn't it?

Yes, but you would still need the extra add-on code.  It just doesn't
belong in Eglot.  It could belong in cc-mode.el (as could
eglot-server-programs's clangd entry, btw) but I heavily doubt the
author of that package would accept it.  The brand new c++-ts-mode and
c-ts-mode is a different story though.  Or it could just be a separate
file to require.  Or a separate GNU ELPA package.

> Kind of surprised clangd doesn't use some kind of namespacing
> convention for their protocol extensions.

Yes.  What's worse, it supports multiple different versions outside and
inside of the standard of the same feature.  I've just seen this with
the textDocument/typeHierarchy method, which is now officially called
textDocument/prepareTypeHierarchy.  So I don't want to add two methods
to support basically the same thing to Eglot.

> Anyway, it would be great if this could be a part of eglot but I can
> understand being careful given it's not in the standard protocol and
> not even in a released clangd yet.
> It would be great though if this example was included in the docs. It
> says a lot about how easy to extend and well designed eglot is.

Make a patch for that (and remember to also include the exportation of
the '--' symbols).

> One thing about UI, all the themes I tried seem to render shadow as
> grey-ish but it was my impression reading the docs that it would be a
> dim version of the current face, so it would still have syntax
> highlighting. Is it just a theme limitation (probably because shadow
> wasn't used for something like this before) or it's not technically
> possible?

I'm fairly sure it's technically possible, even if perhaps not easy.
You can investigate or ask this on emacs-devel.

João