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

[João Távora]

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.