bug#65517: 30.0.50; Eglot: word list input

bug#65517: 30.0.50; Eglot: word list input

[Gerd Möllmann]

THe prompt of C-M-. advertises that the user can enter a list of words
for search for, but that doesn't seem to be supported ATM.

For example, C-M-. Lisp_Package RET works fine, but entering a word
list, say "Li Pa", does not.

In GNU Emacs 30.0.50 (build 2, aarch64-apple-darwin22.6.0, NS
 appkit-2299.70 Version 13.5 (Build 22G74)) of 2023-08-24 built on
 Mini.fritz.box
Repository revision: 53c07bd04bf59f63e49af2c626714bf3fdd03ad6
Repository branch: scratch/pkg
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.5

bug#65517: 30.0.50; Eglot: word list input

[João Távora]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> THe prompt of C-M-. advertises that the user can enter a list of words
> for search for, but that doesn't seem to be supported ATM.

C-M-. is bound to the command 'xref-find-apropos'.  Eglot has installed
a backend for this command.  

   (cl-defmethod xref-backend-apropos ((_backend (eql eglot)) pattern)

If you look into the implementation you'll see it uses the LSP
'workspace/symbol' request.  That interface is described in

   https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_symbol

The sparsely described 'query' field doesn't seem to explicitly support
'multiple word' searches of 'multiple word fragment' searches out of the
box.  Furthermore each LSP server implementation can more or less
interpret this freely.  Some LSP server implementation might even
support pattern-matching or even regexps there but it doesn't seem like
'clangd' (the server I presume you are using) does this.

You can see the communication in the Eglot events buffer.  For example
here's me trying to query for "ma loc" and getting no replies:

   [client-request] (id:32) Fri Aug 25 09:48:56 2023:
   (:jsonrpc "2.0" :id 32 :method "workspace/symbol" :params
             (:query "ma loc"))
   [stderr] I[09:48:56.386] <-- workspace/symbol(32)
   [server-reply] (id:32) Fri Aug 25 09:48:56 2023:
   (:id 32 :jsonrpc "2.0" :result [])

If I query for 'malloc' instead, I get loads of hits.

João

bug#65517: 30.0.50; Eglot: word list input

[Gerd Möllmann]

João Távora <joaotavora@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> THe prompt of C-M-. advertises that the user can enter a list of words
>> for search for, but that doesn't seem to be supported ATM.
>
> C-M-. is bound to the command 'xref-find-apropos'.  Eglot has installed
> a backend for this command.  
>
>    (cl-defmethod xref-backend-apropos ((_backend (eql eglot)) pattern)
>
> If you look into the implementation you'll see it uses the LSP
> 'workspace/symbol' request.  That interface is described in
>
>    https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_symbol
>
> The sparsely described 'query' field doesn't seem to explicitly support
> 'multiple word' searches of 'multiple word fragment' searches out of the
> box.  Furthermore each LSP server implementation can more or less
> interpret this freely.  Some LSP server implementation might even
> support pattern-matching or even regexps there but it doesn't seem like
> 'clangd' (the server I presume you are using) does this.
>
> You can see the communication in the Eglot events buffer.  For example
> here's me trying to query for "ma loc" and getting no replies:
>
>    [client-request] (id:32) Fri Aug 25 09:48:56 2023:
>    (:jsonrpc "2.0" :id 32 :method "workspace/symbol" :params
>              (:query "ma loc"))
>    [stderr] I[09:48:56.386] <-- workspace/symbol(32)
>    [server-reply] (id:32) Fri Aug 25 09:48:56 2023:
>    (:id 32 :jsonrpc "2.0" :result [])
>
> If I query for 'malloc' instead, I get loads of hits.

Thanks for the technical explanation, I appreciate that.

I'm purely looking at things as a user, though: I see the prompt of
C-M-. mentions that I can enter a word list, and of course I'm trying
that out. I know or find out what word-list means, for instance because
the doc string of 'apropos' says

  PATTERN can be a word, a list of words (separated by spaces),
  or a regexp (using some regexp special characters).  If it is a word,
  search for matches for that word as a substring.  If it is a list of words,
  search for matches for any two (or more) of those words.

Now I'm simply wondering if what C-M-. does in this case fits that description.
Nothing more. I'm not saying anything should be implemented or whatever
else.  If you find the current state okay, that's fine with me.

bug#65517: 30.0.50; Eglot: word list input

[João Távora]

On Sat, Aug 26, 2023 at 5:55 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>

> Thanks for the technical explanation, I appreciate that.
>
> I'm purely looking at things as a user, though:

Right, but by some accounts at least, you're also a programmer :-)
and since this list is also read by others, and who knows the future
maintainer of Eglot, I think a bit of technical context is worth it.

To give yet another perspective,  Xref and LSP were invented
independently.  The first was modelled vaguely on SLIME and Lisp machines,
the second on god knows what, probably visual studio's internals?
Anyway, Eglot is the matchmaker and it's not always a perfect marriage.
You'll find lots of examples of this with LSP and Emacs's parts
(completion, flymake, imenu)-- it's not only xref.

Anyway, glad I could be of assistance and I think we can close this.

João

bug#65517: 30.0.50; Eglot: word list input

[Dmitry Gutov]

On 26/08/2023 07:55, Gerd Möllmann wrote:
>    PATTERN can be a word, a list of words (separated by spaces),
>    or a regexp (using some regexp special characters).  If it is a word,
>    search for matches for that word as a substring.  If it is a list of words,
>    search for matches for any two (or more) of those words.
> 
> Now I'm simply wondering if what C-M-. does in this case fits that description.
> Nothing more. I'm not saying anything should be implemented or whatever
> else.  If you find the current state okay, that's fine with me.

Perhaps this documentation is in need of an update. Not sure how to 
better phrase it, though. Just say that elisp and etags do this and the 
rest do the best they can? :)

LSP is great, but a lot of edge cases differ between the servers. That 
is improving over time, but I don't know whether there is point in 
reporting/waiting for this one to even out.