From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#65418: 29.1; Eglot: support clangd inactiveRegions extension Date: Tue, 22 Aug 2023 09:56:24 +0100 Message-ID: References: <87edjw6wtz.fsf@betli.tmit.bme.hu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000030fd3c06037f2cd1" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5641"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65418@debbugs.gnu.org, Philip Kaludercic , Felician Nemeth To: Filippo Argiolas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 22 10:57:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qYNCK-0001Hj-Fz for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Aug 2023 10:57:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qYNCF-0001jH-6Q; Tue, 22 Aug 2023 04:57:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qYNC8-0001iB-0F for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2023 04:57:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qYNC7-0001fc-Jg for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2023 04:56:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qYNCA-0005Zy-8k for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2023 04:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2023 08:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65418 X-GNU-PR-Package: emacs Original-Received: via spool by 65418-submit@debbugs.gnu.org id=B65418.169269460921427 (code B ref 65418); Tue, 22 Aug 2023 08:57:02 +0000 Original-Received: (at 65418) by debbugs.gnu.org; 22 Aug 2023 08:56:49 +0000 Original-Received: from localhost ([127.0.0.1]:58550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYNBx-0005ZW-48 for submit@debbugs.gnu.org; Tue, 22 Aug 2023 04:56:49 -0400 Original-Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]:51702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYNBu-0005ZH-Ho for 65418@debbugs.gnu.org; Tue, 22 Aug 2023 04:56:47 -0400 Original-Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2bcb0b973a5so39584131fa.3 for <65418@debbugs.gnu.org>; Tue, 22 Aug 2023 01:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692694598; x=1693299398; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1/LQHXRNIvxjZ4M3kMzXNZH07p8rRsA/RDfwlO3ixSI=; b=UjOenffkFucnkWMKCo1Zjllo9WgqcKgthvaOVfnZXpyHZILdgK2K5IQGKvFAKk4THH Tk5R0janfCPM0ESkwUSHrBkr1u4O1hq4kC8zaVgw16zTyq5wWv7F8UIBCyye9I/QvFgS v/GlOy85OeirW3+Gl0mwboPbp5yyyQ5LIZsQwofR5DXRN1Bb2C2E6ws8QYdAWaclKiS7 sAmEf5bWg12hDO2xWT+x38ReC5sLLvIoOVEhkM43v4fZvuRmzErFM/8cd9lbK5avAuhZ ClwOglwdv27ZbgY4BQ3EIoaYVeNSoiaFhBCWv6p9OFrumeww9tH1r5Myq8oza5e3cMH6 JJjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692694598; x=1693299398; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1/LQHXRNIvxjZ4M3kMzXNZH07p8rRsA/RDfwlO3ixSI=; b=E97z6xMEDvuwZVmXeDtphqVWBllmw5tDMhI/hxe+m+X/cuTFn3YlZWz3m3K12wl7xs 7oAJ7moR7RyYWc7FX5AmfVIlkXiZ6+ipCQlLm2N3n+jJiXIMCxT0KlT/apBXs6a79icU wZ3pxOnfNOTAH8GORBQ7mXJBfkYhipG3aeIp7G3TBezIHNOMopLJHZQYI5LsBCCRL+RM cF0w7q0UGlSNS7T8FKznUBcIacB680iXbDGbeBqcHAvVzyz9su1idUKQEPb/fO1uODDC 6g/TsLGHAs1z6bXk5tgw8oZ0hVly8yy+ZEsMoPzo7VEecaV+RKiGhLcQr2ZPYwtnjWWu ZBBA== X-Gm-Message-State: AOJu0YwOO1T13vLyBsf4FmL/NXW2Vv+nbdYGLiIzWJp7Fw9MI9q5MQBL zNPFV1jvb0d9wgCytiD8J1Si0Uv3fMSrgODNcGQ= X-Google-Smtp-Source: AGHT+IE7K+Fe7DGkd5PodN6dKSahFcEaM+lrlXn9C4EKqdTmQHhHxAdLyC7+YwZSL8dzS3vAUYteQJbsVgtzQfHkuo4= X-Received: by 2002:a2e:8416:0:b0:2b6:ddab:506a with SMTP id z22-20020a2e8416000000b002b6ddab506amr6996483ljg.34.1692694597400; Tue, 22 Aug 2023 01:56:37 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268157 Archived-At: --00000000000030fd3c06037f2cd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2023, 08:09 Filippo Argiolas wrote: > In the past, Jo=C3=A3o 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=C3=A3o --00000000000030fd3c06037f2cd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 22, 2023, 08:09 Filippo Argiolas <filippo.argiolas@gmail.com> w= rote:

> In the past, Jo=C3=A3o wasn't keen on supporting non-standard feat= ures in
> Eglot.=C2=A0 I Cc'd him anyway as he is the maintainer of Eglot.

Ri= ght, but I'm not for making it hard either. Although this is non-standa= rd, it's similar to a bunch of "code-painting" situations, so= me of which are standard, and some of which, like inlay hints are already i= n Eglot.

So it shouldn&#= 39;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 t= o 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 t= hat in the past, but it's not very practical every time, so either we w= ait 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 befo= re 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 region= s. 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 f= eature. But how likely is it that this makes it into the LSP standard, in y= our opinion?

FWIW, other= languages have similar features. Common Lisp has read-time conditionals fo= r example, which are similar if not identical in function (and obviously no= t 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 acti= ve, 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 philo= sophy, but these "standard components" differ in quality immensel= y. So it's on a case-by-case.

Jo=C3=A3o
--00000000000030fd3c06037f2cd1--