From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Eglot: auto-import completion item Date: Thu, 17 Nov 2022 10:41:46 +0000 Message-ID: References: <83a64pewpw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000093ee2b05eda8384c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24108"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Marcin Pajkowski , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 17 11:41:20 2022 Return-path: Envelope-to: ged-emacs-devel@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 1ovcKe-000669-E1 for ged-emacs-devel@m.gmane-mx.org; Thu, 17 Nov 2022 11:41:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovcKC-0001VS-6q; Thu, 17 Nov 2022 05:40:52 -0500 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 1ovcKB-0001V9-5K for emacs-devel@gnu.org; Thu, 17 Nov 2022 05:40:51 -0500 Original-Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ovcK6-0004hW-7m; Thu, 17 Nov 2022 05:40:50 -0500 Original-Received: by mail-ot1-x32e.google.com with SMTP id m7-20020a9d6447000000b0066da0504b5eso766871otl.13; Thu, 17 Nov 2022 02:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kKlufdzNDNCm+vvKiBoCAwGFNQ4YmbEQx+AUMogWeSM=; b=p52GeNyaZaXJXa0hpXiIUk3CuVwr+UndcyrqA/N3uPiVsIQh3MyJjEeMHQBO4ijyOl 7EbXLsaquajJuvftMudS/80yyPGNj2B/lzDJ1y4YOxdIF7K9QpgiyhFbSihZ73+UxBxJ rqNiWa49wMyqq+ZpeRsASAsiy/GAroXZlth8ZB9JmUcI9DVTtlJgDg9TA6OnOfRJnEjx c4iTKpEE48WrSfH4GQ+6s5oI9hT7InEHPkwRhHGgW1dM6Hsk2V6hbGoMi0C6cYuBHf+Y 2SjD94HOjbl/LZyR6WktAmtYqQMg032H3P7GzjF34y00NbgOietABcjAHJ2PDUuVLbrE fQRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=kKlufdzNDNCm+vvKiBoCAwGFNQ4YmbEQx+AUMogWeSM=; b=hDIsr4RFhsmnHdDzFJ6VT26CRsFVyw1dsPYENsX/w/V4R+RbMELVwv3G/TvapfYLTB KFwIN/52BVcCkwVYX3KJAuuRDNaz47RrFI1HinOWH2dP+ysOzbxGc8VUMlYECOBHlDP1 6fPD4J2UnvB4BcIbRnIZp4Vba8U/DxGsvWyWPNpbmD1OeiW1hEp3Dg+VfMgMhJpmm6SD nawuR8RoWl3sGonKk/fPrW2irVw8GvAokv+Bs93gJXv0fpcNk8vYf79/zWaC5p4MRD3c I8FBbSWEhvsOZWMjKOvkew99AXEjSbMb63w2uqoRatDoM966wBGbqCmnL7UtFdhSf3++ QWKg== X-Gm-Message-State: ANoB5pl+IRkaRjmevVnet8f35IOAPjURtgIFIO9KC8q8SbvTIMvFbdl9 eoMGGjcioI4t9osVdiyQg2Hyz6OjreexeUDl1NezF5AoyoALBg== X-Google-Smtp-Source: AA0mqf5m+nl+VP2B8+WpzswHqFfnHFwRfsk9Bfnk05utk1pmfYPpqYvAoSSuM9KCT1Y0cibKv12JHaV5WD6TisRc3yY= X-Received: by 2002:a9d:4f07:0:b0:66c:64d6:1bb4 with SMTP id d7-20020a9d4f07000000b0066c64d61bb4mr1028278otl.201.1668681643059; Thu, 17 Nov 2022 02:40:43 -0800 (PST) In-Reply-To: <83a64pewpw.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::32e; envelope-from=joaotavora@gmail.com; helo=mail-ot1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300038 Archived-At: --00000000000093ee2b05eda8384c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What these particular capabilities are about can be seen in the LSP spec. I haven't checked, but I think this refers to Eglot's capability to present meta information about a given completion item and to do additional things elsewhere in the buffer once a given completion item is chosen by the user. So, typically you may be given the completion: std::cout and if you do choose it, Eglot and LSP try to ensure that an #include appears in the top of your C++ file. In general, normally both client and server advertise their capabilities to each other so that the other side refrains from doing anything that is not explicitly mentioned in these advertisements. This is how there are really no "versions of the protocol" (well there are, but they aren't used in the way a normal versioned API is used). It doesn't always work that way, and both clients and servers will both request stuff that isn't possible and volunteer stuff that isn't needed. It's indeed odd to find that Eglot starts advertising a capability just by itself, without adding any new functional code presumably backing that advertisement, so you're right to be suspicious, Eli. But it may be just that the advertisement was incorrectly glossed over in the past (which wouldn't necessarily present a problem since many servers don't bother to check advertisements, as explained), or -- also possible -- that the advertisement wasn't even specified in the past. Most importantly, I would like Marcin to explain, if possible, what actual problem with what server this is solving. The reasoning and conclusion should be in the commit message for this patch for future reference. Jo=C3=A3o On Thu, Nov 17, 2022 at 9:50 AM Eli Zaretskii wrote: > > From: Marcin Pajkowski > > Date: Sat, 12 Nov 2022 14:23:52 +0100 > > > > * lisp/progmodes/eglot.el (eglot-client-capabilities): Advertise > > resolveSupport capabilities > > --- > > lisp/progmodes/eglot.el | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el > > index 63ebbe6cab..953c0f45fc 100644 > > --- a/lisp/progmodes/eglot.el > > +++ b/lisp/progmodes/eglot.el > > @@ -736,6 +736,7 @@ eglot-client-capabilities > > t > > :json-false) > > :deprecatedSupport t > > + :resolveSupport (:properties > ["documentation" "details" "additionalTextEdits"]) > > :tagSupport (:valueSet [1])) > > :contextSupport t) > > :hover (list :dynamicRegistration :json-fals= e > > -- > > 2.38.1 > > Jo=C3=A3o, what about this one? Should we install it? What are > resolveSupport capabilities about? > > --=20 Jo=C3=A3o T=C3=A1vora --00000000000093ee2b05eda8384c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What these particular capabilities are about can be s= een
in the LSP spec.=C2=A0 I haven't checked, but=C2=A0 I thi= nk this refers to
Eglot's capability to present meta informat= ion about a given
completion item and to do additional thing= s elsewhere in the
buffer once a given completion item is ch= osen by the user.=C2=A0
So, typically you may be given the c= ompletion:

=C2=A0=C2=A0 std::cout

and if you do choose it, Eglot and LSP try to ensure that
an #include <iostream> appears in the top of your C++ file.

In general, normally both client and server advertise= their
capabilities to each other so that the other side ref= rains from
doing anything that is not explicitly mentioned in the= se
advertisements.=C2=A0 This is how there are really no "ve= rsions of
the protocol" (well there are, but they aren't= used in the way
a normal versioned API is used).=C2=A0 It doesn&= #39;t always work that
way, and both clients and servers will bot= h request stuff that
isn't possible and volunteer stuff that = isn't needed.

It's indeed odd to find = that Eglot starts advertising a
capability just by itself, witho= ut adding any new functional
code presumably backing that adverti= sement, so you're right
to be suspicious, Eli.
=
But it may be just that the advertisement was incorrectly
glossed over in the past (which wouldn't necessarily presen= t
a problem since many servers don't bother to check
advertisements, as explained), or -- also possible -- that the
= advertisement wasn't even specified in the past.

Most importantly, I would like Marcin to explain, if possible,
what actual problem with what server this is solving.=C2=A0

The reasoning and conclusion should be in the commit messag= e
for this patch for future reference.

Jo=C3=A3o

On Thu, Nov 17, 2022 at 9:50 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Marcin Pajkowski <marcin.pajkow= ski@gmail.com>
> Date: Sat, 12 Nov 2022 14:23:52 +0100
>
> * lisp/progmodes/eglot.el (eglot-client-capabilities): Advertise
> resolveSupport capabilities
> ---
>=C2=A0 lisp/progmodes/eglot.el | 1 +
>=C2=A0 1 file changed, 1 insertion(+)
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index 63ebbe6cab..953c0f45fc 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -736,6 +736,7 @@ eglot-client-capabilities
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0:json-false)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :depr= ecatedSupport t
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :resolveSup= port (:properties ["documentation" "details" "addi= tionalTextEdits"])
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :tagS= upport (:valueSet [1]))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :contextSupp= ort t)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:hover=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (list :dynamicRegistration :json-fal= se
> --
> 2.38.1

Jo=C3=A3o, what about this one?=C2=A0 Should we install it?=C2=A0 What are<= br> resolveSupport capabilities about?



--
Jo=C3=A3o T=C3=A1vora
--00000000000093ee2b05eda8384c--