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

[Theodor Thornhill]

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