Hi Emacs developers,

I use clangd and rust-analyzer LSP servers and found this issue
is specific to rust-analyzer.

This advertisement is required by rust-analyzer server
to provide completions for symbols that are not resolved
but can be automatically imported. Without advertising, this capability
server does not report such completions, which kind of makes sense IMHO:

- server can avoid some computations,
- client which does not support additionalTextEdits capability
  doesn't receive items that can't be auto-imported. User of such
  LSP client could probably consider such suggestions inaccurate
  (I applied completion and my code does not compile).

Reference:
https://rust-analyzer.github.io/manual.html#completion-with-autoimport

I reflected my clarifications in a commit message and put the patch
in a separate file.

Best regards,
Marcin

czw., 17 lis 2022 o 11:40 João Távora <joaotavora@gmail.com> napisał(a):

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