unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Marcin Pajkowski <marcin.pajkowski@gmail.com>, emacs-devel@gnu.org
Subject: Re: [PATCH] Eglot: auto-import completion item
Date: Thu, 17 Nov 2022 10:41:46 +0000	[thread overview]
Message-ID: <CALDnm51O0RvwQNSXe+XCC_B3=SHud_montKLrycYcCcugcKekw@mail.gmail.com> (raw)
In-Reply-To: <83a64pewpw.fsf@gnu.org>

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

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 <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 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ão

On Thu, Nov 17, 2022 at 9:50 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Marcin Pajkowski <marcin.pajkowski@gmail.com>
> > 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-false
> > --
> > 2.38.1
>
> João, what about this one?  Should we install it?  What are
> resolveSupport capabilities about?
>
>

-- 
João Távora

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

  reply	other threads:[~2022-11-17 10:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-12 13:23 [PATCH] Eglot: auto-import completion item Marcin Pajkowski
2022-11-17  9:50 ` Eli Zaretskii
2022-11-17 10:41   ` João Távora [this message]
2022-11-20 20:52     ` Marcin Pajkowski
2022-11-21 13:56       ` João Távora
2022-11-22 20:26         ` Marcin Pajkowski

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='CALDnm51O0RvwQNSXe+XCC_B3=SHud_montKLrycYcCcugcKekw@mail.gmail.com' \
    --to=joaotavora@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=marcin.pajkowski@gmail.com \
    /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).