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?