bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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


Hi Joao and others!

As I mentioned in a different Eglot bug I believed there was a problem
with sorting of candidates.  It seems there kinda is, but it's a little
convoluted.  To test this you need to have a server that supplies
snippets, or at least that sends some items with and without :sortText.
However, the code is simple enough, so it should be enough to read it.

So, what happens with completion in Eglot that I find confusing is that
sometimes, candidates in the completion frameworks (company, corfu etc)
display candidates in a seemingly random order compared to what the
server sends.  In particular, the Jdtls server sends snippets without
sorttext, which will be converted to the empty string in the sorter
function.  That in turn will make all the snippets fall to the front of
the list as (string-lessp "" "anything else") evaluates to t.  That
means we ignore the sorts supplied by the server.  Because (string-lessp
nil "anything else") evaluates to nil it will put them at the end of the
list, which IMO makes more sense.

In addition, the completion-category-defaults set by eglot uses flex, as
you know, so the display-sort-function will sort them very hungrily,
making them seem out of order.

For example, if the candidates are (delete, deleteAll, deleteById) when
buffer content is (| is point):

```
something.del|
```

completion will display them in this order: (deleteAll, deleteById,
delete), which yet again "doesn't respect sort order".  The latter issue
is fixed by setting

(setq completion-category-overrides
      '((eglot (styles basic partial-completion initials))))

or something else, which works, but is very convoluted and really not
documented anywhere, or did I miss it?

The former issue is fixed in the supplied patch.  Do you agree with what
I propose?  We could also default to something like :label or
:insertText, but that would in some cases also likely conflict with what
the server is expected to send.

Theo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-completions-without-sortText-fall-to-back-of-th.patch --]
[-- Type: text/x-patch, Size: 1454 bytes --]

From 6b5c37f00f73abf07a72d2bc2fe6edb99f8ee0a4 Mon Sep 17 00:00:00 2001
From: Theodor Thornhill <theo@thornhill.no>
Date: Wed, 15 Feb 2023 15:16:15 +0100
Subject: [PATCH] Make completions without :sortText fall to back of the list

* lisp/progmodes/eglot.el: String-lessp is safe with (string-lessp nil
"foo") and (string-lessp "foo" nil), but defaulting to the empty
string puts candidates to the top of the list.  Nil will make the
candidates fall to the end of the list.
---
 lisp/progmodes/eglot.el | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 5e761d3064f..c8620f4199f 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -2782,10 +2782,9 @@ eglot-completion-at-point
               (cl-sort completions
                        #'string-lessp
                        :key (lambda (c)
-                              (or (plist-get
-                                   (get-text-property 0 'eglot--lsp-item c)
-                                   :sortText)
-                                  "")))))
+                              (plist-get
+                               (get-text-property 0 'eglot--lsp-item c)
+                               :sortText)))))
            (metadata `(metadata (category . eglot)
                                 (display-sort-function . ,sort-completions)))
            resp items (cached-proxies :none)
-- 
2.34.1

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Ping :-)

Theodor Thornhill <theo@thornhill.no> writes:

> Hi Joao and others!
>
> As I mentioned in a different Eglot bug I believed there was a problem
> with sorting of candidates.  It seems there kinda is, but it's a little
> convoluted.  To test this you need to have a server that supplies
> snippets, or at least that sends some items with and without :sortText.
> However, the code is simple enough, so it should be enough to read it.
>
> So, what happens with completion in Eglot that I find confusing is that
> sometimes, candidates in the completion frameworks (company, corfu etc)
> display candidates in a seemingly random order compared to what the
> server sends.  In particular, the Jdtls server sends snippets without
> sorttext, which will be converted to the empty string in the sorter
> function.  That in turn will make all the snippets fall to the front of
> the list as (string-lessp "" "anything else") evaluates to t.  That
> means we ignore the sorts supplied by the server.  Because (string-lessp
> nil "anything else") evaluates to nil it will put them at the end of the
> list, which IMO makes more sense.
>
> In addition, the completion-category-defaults set by eglot uses flex, as
> you know, so the display-sort-function will sort them very hungrily,
> making them seem out of order.
>
> For example, if the candidates are (delete, deleteAll, deleteById) when
> buffer content is (| is point):
>
> ```
> something.del|
> ```
>
> completion will display them in this order: (deleteAll, deleteById,
> delete), which yet again "doesn't respect sort order".  The latter issue
> is fixed by setting
>
> (setq completion-category-overrides
>       '((eglot (styles basic partial-completion initials))))
>
> or something else, which works, but is very convoluted and really not
> documented anywhere, or did I miss it?
>
> The former issue is fixed in the supplied patch.  Do you agree with what
> I propose?  We could also default to something like :label or
> :insertText, but that would in some cases also likely conflict with what
> the server is expected to send.
>
> Theo

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[João Távora]

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

On Sat, Feb 18, 2023 at 10:18 PM Theodor Thornhill <theo@thornhill.no>
wrote:

>
> Ping :-)


[Thanks for the ping. Without it, i would probably not be aware of the
message
which was primarily intented for me, since I'm not (at the present)
following the
bug tracker list.  Next time, you can add me to the special X-Debbugs-CC:
header]

To your patch, I think it is quite acceptable.  I've pushed it to emacs-29.

I'll keep the bug open, since there is also the second problem which I
still don't
quite understand, but it looks like a bug, too.  But I think I have enough
information
to investigate on my own for now.

João

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

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 19 February 2023 12:13:46 CET, "João Távora" <joaotavora@gmail.com> wrote:
>On Sat, Feb 18, 2023 at 10:18 PM Theodor Thornhill <theo@thornhill.no>
>wrote:
>
>>
>> Ping :-)
>
>
>[Thanks for the ping. Without it, i would probably not be aware of the
>message
>which was primarily intented for me, since I'm not (at the present)
>following the
>bug tracker list.  Next time, you can add me to the special X-Debbugs-CC:
>header]

Pretty sure I did that, but it doesn't matter :)


>
>To your patch, I think it is quite acceptable.  I've pushed it to emacs-29.
>

Great news!

>I'll keep the bug open, since there is also the second problem which I
>still don't
>quite understand, but it looks like a bug, too.  But I think I have enough
>information
>to investigate on my own for now.
>
>João

I don't think it's a bug, really. Isn't it just the flex style greediness? It feels like it tries to match the longest string possible alphabetically? It's just unintuitive because the json results doesn't match the output, and debugstepping over was very unhelpful. We could maybe just add some docs explaining that eglot default, which for many really is an eglot hard-coding.

But not sure, and the workaround in the report works anyways :)

Theo

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[João Távora]

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

On Sun, Feb 19, 2023 at 4:08 PM Theodor Thornhill <theo@thornhill.no> wrote:
>
>
> >bug tracker list.  Next time, you can add me to the special X-Debbugs-CC:
> >header]
> Pretty sure I did that, but it doesn't matter :)

[ I didn't get the message. I went to look in the mbox file off Debbugs and
I did
find a 'X-Debbugs-Cc' header, but maybe it has to be 'X-Debbugs-CC'?]

> I don't think it's a bug, really. Isn't it just the flex style greediness?

The 'flex' completion style isn't really doing (or at shouldn't be doing)
what it does normally. Its purpose in Eglot is only to allow for flex-style
fontification of the pattern to happen. Nothing more, and that includes
no sorting.

That's because, contrary to the normal uses of flex, here it's the
server which does all the selection and the filtering for whatever
it thinks is a pattern.  It turns out that a very common style of filtering
among servers is akin to 'flex', so using flex on our side to "paint"
the pattern in the completion candidate is usually, though not always,
a good bet.  If the server happens to use 'prefix' ,then 'flex' will also
paint it correctly, in principle. This is of course presuming we guess
the filter pattern that the server used, which we're not guaranteed
to, but more or less always do by looking for a 'symbol' thing-at-point.

Anyway, flex shouldn't be doing any kind of completion sorting for
eglot-completion-at-point. So if it is doing that, it's IMO a bug (though
perhaps not a serious one, as it wouldn't be a very absurd sorting
anyway).

> It feels like it tries to match the longest string possible
alphabetically? It's
> just unintuitive because the json results doesn't match the output, and
> debug stepping over was very unhelpful. We could maybe just add
> some docs explaining that eglot default, which for many really is an
eglot
> hard-coding.

I hope I explained why it's there.  This is what I recall of it, though
I may be misremembering.  You could help improve the documentation
by confirming my recollection hypothesis and adding comments to the
code.

Anyway, this boils down to a limitation of LSP, that it doesn't report on
what
kind of matching style it uses for textDocument/completion.  At least it
used to be a limitation of LSP, maybe someone else has fixed it in the
meantime, or added something that we can use.

João

PS: Added Stefan and Augusto to the discussion since I think they are
already familiar with this LSP/Emacs discrepancy regarding completion
systems and completion philosophy.

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

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

João Távora [2023-02-19 18:19 +0000] wrote:

> On Sun, Feb 19, 2023 at 4:08 PM Theodor Thornhill <theo@thornhill.no> wrote:
>>
>> >bug tracker list.  Next time, you can add me to the special X-Debbugs-CC:
>> >header]
>> Pretty sure I did that, but it doesn't matter :)
> [ I didn't get the message. I went to look in the mbox file off Debbugs and I did
> find a 'X-Debbugs-Cc' header, but maybe it has to be 'X-Debbugs-CC'?]

I routinely use the former (I copy it out of admin/notes/bugtracker each
time, and ironically just opened this message of yours to copy your
email address for another report I'm about to send in ;).

-- 
Basil

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> João Távora [2023-02-19 18:19 +0000] wrote:
>
>> On Sun, Feb 19, 2023 at 4:08 PM Theodor Thornhill <theo@thornhill.no> wrote:
>>>
>>> >bug tracker list.  Next time, you can add me to the special X-Debbugs-CC:
>>> >header]
>>> Pretty sure I did that, but it doesn't matter :)
>> [ I didn't get the message. I went to look in the mbox file off Debbugs and I did
>> find a 'X-Debbugs-Cc' header, but maybe it has to be 'X-Debbugs-CC'?]
>
> I routinely use the former (I copy it out of admin/notes/bugtracker each
> time, and ironically just opened this message of yours to copy your
> email address for another report I'm about to send in ;).
>
> -- 
> Basil

Yeah, that's strange.  I got this from the ack:


As you requested using X-Debbugs-CC, your message was also forwarded to
  joaotavora@gmail.com
(after having been given a bug report number, if it did not have one).

When submitting the bug...

Wellwell.

Theo

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Yeah, that's strange.  I got this from the ack:
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   joaotavora@gmail.com
> (after having been given a bug report number, if it did not have one).
>
> When submitting the bug...
>
> Wellwell.

It may simply be Gmail being Gmail (i.e. rejecting email that's not
"direct from a Gmail-like service provider").


        Stefan

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[João Távora]

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

On Sun, Feb 19, 2023, 22:47 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Yeah, that's strange.  I got this from the ack:
> >
> > As you requested using X-Debbugs-CC, your message was also forwarded to
> >   joaotavora@gmail.com
> > (after having been given a bug report number, if it did not have one).
> >
> > When submitting the bug...
> >
> > Wellwell.
>
> It may simply be Gmail being Gmail (i.e. rejecting email that's not
> "direct from a Gmail-like service provider").


I did get Basil's X-Debbugs-CC, FWIW, but not Theodor's.

João

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

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> It may simply be Gmail being Gmail (i.e. rejecting email that's not
>> "direct from a Gmail-like service provider").
> I did get Basil's X-Debbugs-CC, FWIW, but not Theodor's.

AFAIK Gmail's rejection algorithm (like most SPAM systems nowadays)
is not deterministic nor documented, so until proof that it's something
else, we can only guess that maybe(?) it's Gmail.

We do know that it tends to cause problems mostly when email is
redirected (mailing list software has had to grow ugly hacks to try and
convince Gmail (and its siblings like Hotmail) to keep accepting their
messages).


        Stefan

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> On Sun, Feb 19, 2023 at 4:08 PM Theodor Thornhill <theo@thornhill.no> wrote:
>>
>>
>> >bug tracker list.  Next time, you can add me to the special X-Debbugs-CC:
>> >header]
>> Pretty sure I did that, but it doesn't matter :)
>
> [ I didn't get the message. I went to look in the mbox file off Debbugs and
> I did
> find a 'X-Debbugs-Cc' header, but maybe it has to be 'X-Debbugs-CC'?]
>
>> I don't think it's a bug, really. Isn't it just the flex style greediness?
>
> The 'flex' completion style isn't really doing (or at shouldn't be doing)
> what it does normally. Its purpose in Eglot is only to allow for flex-style
> fontification of the pattern to happen. Nothing more, and that includes
> no sorting.
>
> That's because, contrary to the normal uses of flex, here it's the
> server which does all the selection and the filtering for whatever
> it thinks is a pattern.  It turns out that a very common style of filtering
> among servers is akin to 'flex', so using flex on our side to "paint"
> the pattern in the completion candidate is usually, though not always,
> a good bet.  If the server happens to use 'prefix' ,then 'flex' will also
> paint it correctly, in principle. This is of course presuming we guess
> the filter pattern that the server used, which we're not guaranteed
> to, but more or less always do by looking for a 'symbol' thing-at-point.
>
> Anyway, flex shouldn't be doing any kind of completion sorting for
> eglot-completion-at-point. So if it is doing that, it's IMO a bug (though
> perhaps not a serious one, as it wouldn't be a very absurd sorting
> anyway).
>

I spent some time trying to understand what was happening inside this
function, which seems to sort, and is triggered upon completion.  Maybe
that's a clue?  I have no idea, honestly, but I remember getting
different results when changing > to < in the middle of it:

```

(defun completion--flex-adjust-metadata (metadata)
  "If `flex' is actually doing filtering, adjust sorting."
  (let ((flex-is-filtering-p
         ;; JT@2019-12-23: FIXME: this is kinda wrong.  What we need
         ;; to test here is "some input that actually leads/led to
         ;; flex filtering", not "something after the minibuffer
         ;; prompt".  E.g. The latter is always true for file
         ;; searches, meaning we'll be doing extra work when we
         ;; needn't.
         (or (not (window-minibuffer-p))
             (> (point-max) (minibuffer-prompt-end))))
        (existing-dsf
         (completion-metadata-get metadata 'display-sort-function))
        (existing-csf
         (completion-metadata-get metadata 'cycle-sort-function)))
    (cl-flet
        ((compose-flex-sort-fn
          (existing-sort-fn) ; wish `cl-flet' had proper indentation...
          (lambda (completions)
            (sort
             (funcall existing-sort-fn completions)
             (lambda (c1 c2)
               (let ((s1 (get-text-property 0 'completion-score c1))
                     (s2 (get-text-property 0 'completion-score c2)))
                 (> (or s1 0) (or s2 0)))))))) ;; This line here
      `(metadata
        ,@(and flex-is-filtering-p
               `((display-sort-function
                  . ,(compose-flex-sort-fn (or existing-dsf #'identity)))))
        ,@(and flex-is-filtering-p
               `((cycle-sort-function
                  . ,(compose-flex-sort-fn (or existing-csf #'identity)))))
        ,@(cdr metadata)))))
```

>> It feels like it tries to match the longest string possible
> alphabetically? It's
>> just unintuitive because the json results doesn't match the output, and
>> debug stepping over was very unhelpful. We could maybe just add
>> some docs explaining that eglot default, which for many really is an
> eglot
>> hard-coding.
>
> I hope I explained why it's there.  This is what I recall of it, though
> I may be misremembering.  You could help improve the documentation
> by confirming my recollection hypothesis and adding comments to the
> code.
>
> Anyway, this boils down to a limitation of LSP, that it doesn't report on
> what
> kind of matching style it uses for textDocument/completion.  At least it
> used to be a limitation of LSP, maybe someone else has fixed it in the
> meantime, or added something that we can use.
>
> João

Yeah, that makes sense.

>
> PS: Added Stefan and Augusto to the discussion since I think they are
> already familiar with this LSP/Emacs discrepancy regarding completion
> systems and completion philosophy.

:thumbsup:

Theo

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Anyway, this boils down to a limitation of LSP, that it doesn't report on
> what kind of matching style it uses for textDocument/completion.

It's not just "matching style".  It's that it's designed under the
premise that all the control is on the LSP server side, and the client
(editor) side just provides a "dumb UI".

A better API is probably harder to design (e.g. you need to define what
is a "matching style", for one), admittedly.

> At least it used to be a limitation of LSP, maybe someone else has
> fixed it in the meantime, or added something that we can use.

Not that I know.  But I think if we want that to happen, we need to move
out of our comfort zone and start participating in discussions over in
VScode land where the decisions are made :-(


        Stefan

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Augusto Stoffel]

On Sun, 19 Feb 2023 at 17:56, Stefan Monnier wrote:

>> Anyway, this boils down to a limitation of LSP, that it doesn't report on
>> what kind of matching style it uses for textDocument/completion.
>
> It's not just "matching style".  It's that it's designed under the
> premise that all the control is on the LSP server side, and the client
> (editor) side just provides a "dumb UI".

This not quite true, actually.  I once proposed a mechanism for the
server to request the editor to "act dumb", but the idea didn't stick.
Also, I gather from the discussion that VS Code does its own sorting and
filterting too.

https://github.com/microsoft/language-server-protocol/issues/898

> A better API is probably harder to design (e.g. you need to define what
> is a "matching style", for one), admittedly.

I think if the server returns all possible candidates with no filtering,
then Emacs would be happy, right?  Apparently some servers do that, as
claimed in the above discussion.  Of course there is one big issue with
this approach, namely the response can be quite big and slow down both
ends of the communication channel.

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Augusto Stoffel]

On Sun, 19 Feb 2023 at 18:19, João Távora wrote:

> The 'flex' completion style isn't really doing (or at shouldn't be doing)
> what it does normally. Its purpose in Eglot is only to allow for flex-style
> fontification of the pattern to happen. Nothing more, and that includes
> no sorting.  

What happens with the “glorified TAGS” kind of servers that do no
filtering on their side?  Apparently those exists, according to the
Github discussion I linked in the other message.

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[João Távora]

On Tue, Feb 21, 2023 at 8:24 AM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
> On Sun, 19 Feb 2023 at 18:19, João Távora wrote:
>
> > The 'flex' completion style isn't really doing (or at shouldn't be doing)
> > what it does normally. Its purpose in Eglot is only to allow for flex-style
> > fontification of the pattern to happen. Nothing more, and that includes
> > no sorting.
>
> What happens with the “glorified TAGS” kind of servers that do no
> filtering on their side?  Apparently those exists, according to the
> Github discussion I linked in the other message.

I think these servers do some kind of filtering.  As "glorified TAGS"
servers they might not be aware of the local context but I presume
they would still _not_ provide the 'fooey' completion if point is
after the characters 'bar'. As to whether they also provide 'bias-rate'
in that case (a so-called flex-match) or just 'barbaz' (a prefix match),
it's completely up to them.

Regardless, there is nothing flex can or should do here, except --
as I mentioned -- guessing how the pattern should be painted on
the completions.

João

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[Augusto Stoffel]

On Tue, 21 Feb 2023 at 12:47, João Távora wrote:

> On Tue, Feb 21, 2023 at 8:24 AM Augusto Stoffel <arstoffel@gmail.com> wrote:
>>
>> On Sun, 19 Feb 2023 at 18:19, João Távora wrote:
>>
>> > The 'flex' completion style isn't really doing (or at shouldn't be doing)
>> > what it does normally. Its purpose in Eglot is only to allow for flex-style
>> > fontification of the pattern to happen. Nothing more, and that includes
>> > no sorting.
>>
>> What happens with the “glorified TAGS” kind of servers that do no
>> filtering on their side?  Apparently those exists, according to the
>> Github discussion I linked in the other message.
>
> I think these servers do some kind of filtering.  As "glorified TAGS"
> servers they might not be aware of the local context but I presume
> they would still _not_ provide the 'fooey' completion if point is
> after the characters 'bar'. As to whether they also provide 'bias-rate'
> in that case (a so-called flex-match) or just 'barbaz' (a prefix match),
> it's completely up to them.
>
> Regardless, there is nothing flex can or should do here, except --
> as I mentioned -- guessing how the pattern should be painted on
> the completions.

I think (based on pure guess) that the glorified TAGS do exactly the
opposite (which is also far more useful): if this is context to enter a
{color,function,animal}, then return all known colors, function or
animals respectively (no filtering).

Just checking, because you seem to say the opposite: does Eglot work
correctly in that situation?

bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list

[João Távora]

On Tue, Feb 21, 2023 at 2:08 PM Augusto Stoffel <arstoffel@gmail.com> wrote:

> > Regardless, there is nothing flex can or should do here, except --
> > as I mentioned -- guessing how the pattern should be painted on
> > the completions.
>
> I think (based on pure guess) that the glorified TAGS do exactly the
> opposite (which is also far more useful): if this is context to enter a
> {color,function,animal}, then return all known colors, function or
> animals respectively (no filtering).

We have different understanding of what "glorified TAGS" are.
Indeed it's the first time I heard the expression and I was just
going on a guess of what it might mean for you.  Anyway, for me,
TAGS is a global thing: it has no understanding of "context",
just an understanding of the literal characters that immediately
precede point.  Such a server matches these characters to a global
list and returns the result.

I agree that using context is far better.  This is what most servers
I know do.  They analyse the code and the contexts and provide
working completions for those contexts.  But I wouldn't call these
servers "glorified TAGS.

> Just checking, because you seem to say the opposite: does Eglot work
> correctly in that situation?

I guess it should...  But speculation is not very useful.  Show me
a reproducible example where it doesn't and it'll be more useful.

João