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: Sun, 27 Aug 2023 15:01:37 +0100 Message-ID: <873504d1oe.fsf@gmail.com> References: <87edjw6wtz.fsf@betli.tmit.bme.hu> <87zg2fnwm0.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18087"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) 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 Sun Aug 27 16:00:27 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 1qaGJX-0004Wf-8r for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Aug 2023 16:00:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaGJ5-0003gs-Tm; Sun, 27 Aug 2023 09:59:59 -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 1qaGJ3-0003YO-TC for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2023 09:59:57 -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 1qaGJ3-0001BW-L6 for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2023 09:59:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qaGJ9-0001Vd-3g for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2023 10:00:03 -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: Sun, 27 Aug 2023 14:00:03 +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.16931447535716 (code B ref 65418); Sun, 27 Aug 2023 14:00:03 +0000 Original-Received: (at 65418) by debbugs.gnu.org; 27 Aug 2023 13:59:13 +0000 Original-Received: from localhost ([127.0.0.1]:45914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qaGIL-0001U7-7E for submit@debbugs.gnu.org; Sun, 27 Aug 2023 09:59:13 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:61865) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qaGIF-0001Th-NF for 65418@debbugs.gnu.org; Sun, 27 Aug 2023 09:59:12 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-31c8a710545so769089f8f.3 for <65418@debbugs.gnu.org>; Sun, 27 Aug 2023 06:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693144736; x=1693749536; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=SLdIMFvANYCR1H+2E6GRPNl5jbPUB5twcl0/By8qYEE=; b=PZqYE9bPhD/MXje36uq0gNE/Ot6g0PH4diT4bzRGfQwbIQTBG+ehadCZNQ2u1vaCgs ivMgGGm0GGRwZ6n3EHRZ4bkkHcL0vixIDCxi/9Eekn/4G29Um/dkiV1/0P5uUqH0be+E tMLZ49trj2haNyqYTD5n5fuxlgjOCEdkd67QnMoUCgP3koPXYHvAQViQTlFEYYDTgqKR 77nxVriNIUMRojFtIGmNfCWraifBGJb6FXlh+DtILjap+hqVEAny2ltyraCoYngihVu+ Sk8rm1exr+HfMI8EKDFsvFIWg00Thp/09oizAQm8e94ZsXSRJKng7PAoHqx+nbWcSchW xaCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693144736; x=1693749536; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=SLdIMFvANYCR1H+2E6GRPNl5jbPUB5twcl0/By8qYEE=; b=YUbPeDcmkVxqm9h28bDUYC6C1PJbFVyOdjYGAAXUgbCyCiZQNUtPmmjAMyImDV/y1h fqLdQJvE16bUu4XS3iKKK5Xmhp4YhYzJU+A9QCnEgEBDpuhydsrhSs4pTyOT5utPKtLX REAumbslrUDbtGH0ldB6rFDo3igBh1ouHMdzI320xQXF4An8UwDJwnPQQ9fkJ5GHFyh6 0HQxyjBg6oU1NXKCS927zFOCIWuP2WNpH7xK86V5igu47Ht58oS2xMFjo+datf90UUsH P+So/ehZaQfRK38cbgyzP8/zKEfWzJxMgd22FFWlnXudRfBO27O43mJS8vBv/Isw16rq vbiA== X-Gm-Message-State: AOJu0YxTSiXHnGGGIskRnbXd5lJJt7SUgja4VBib/7kanD2WRN5Ku4my QcjHxBsb/Qrkj3FQDpFFoSI= X-Google-Smtp-Source: AGHT+IHZfoJrSRVRWrY6J/b0LNuHLvd5Fsep9GFPstDfQ4FjKJEj9Ah6lXfhaij5YWEtl2N/7nYQrw== X-Received: by 2002:a5d:4a12:0:b0:318:7bc:122e with SMTP id m18-20020a5d4a12000000b0031807bc122emr17957590wrq.23.1693144735796; Sun, 27 Aug 2023 06:58:55 -0700 (PDT) Original-Received: from krug ([87.196.73.195]) by smtp.gmail.com with ESMTPSA id v7-20020adfe4c7000000b003176aa612b1sm7749085wrm.38.2023.08.27.06.58.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Aug 2023 06:58:55 -0700 (PDT) In-Reply-To: (Filippo Argiolas's message of "Sun, 27 Aug 2023 12:52:58 +0200") 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:268553 Archived-At: Filippo Argiolas writes: > On Fri, Aug 25, 2023 at 2:16=E2=80=AFPM Jo=C3=A3o T=C3=A1vora wrote: >> >> Filippo Argiolas 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=C3=A3o