unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Filippo Argiolas <filippo.argiolas@gmail.com>
Cc: 65418@debbugs.gnu.org, Philip Kaludercic <philipk@posteo.net>,
	Felician Nemeth <felician.nemeth@gmail.com>
Subject: bug#65418: 29.1; Eglot: support clangd inactiveRegions extension
Date: Tue, 22 Aug 2023 09:56:24 +0100	[thread overview]
Message-ID: <CALDnm50Gy953X1NGeosxuwzWRZosjV+NhzytfJQ1BrqZ7oRHzQ@mail.gmail.com> (raw)
In-Reply-To: <CAOdrLGLxxH3Uqh2LfsZc-afB4hXajg8s=nQZy71=mZzVmiB+Dw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]

On Tue, Aug 22, 2023, 08:09 Filippo Argiolas <filippo.argiolas@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

[-- Attachment #2: Type: text/html, Size: 3869 bytes --]

  reply	other threads:[~2023-08-22  8:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-21  8:41 bug#65418: 29.1; Eglot: support clangd inactiveRegions extension Filippo Argiolas
2023-08-21 16:57 ` Philip Kaludercic
2023-08-21 19:04 ` Felician Nemeth
2023-08-22  7:09   ` Filippo Argiolas
2023-08-22  8:56     ` João Távora [this message]
2023-08-22 11:02       ` Filippo Argiolas
2023-08-25 12:18         ` João Távora
2023-08-27 10:52           ` Filippo Argiolas
2023-08-27 14:01             ` João Távora
2023-08-31 17:28               ` Filippo Argiolas
2023-09-04  1:05                 ` João Távora
2023-09-04  1:08                   ` João Távora
2023-09-04  3:59                     ` Filippo Argiolas
2023-09-04  4:09                       ` Filippo Argiolas
2023-09-04 10:51                         ` João Távora
2023-09-04 12:44                           ` Eli Zaretskii
2023-09-04 12:49                             ` João Távora
2023-09-04 16:17                               ` Eli Zaretskii
2023-09-04 20:37                                 ` João Távora
2023-09-04 11:41                     ` Eli Zaretskii
2023-09-02  8:14               ` Filippo Argiolas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALDnm50Gy953X1NGeosxuwzWRZosjV+NhzytfJQ1BrqZ7oRHzQ@mail.gmail.com \
    --to=joaotavora@gmail.com \
    --cc=65418@debbugs.gnu.org \
    --cc=felician.nemeth@gmail.com \
    --cc=filippo.argiolas@gmail.com \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).