bug#45260: 28.0.50; Maybe flex should only sort when there is no sorting metadata?

[Dmitry Gutov <dgutov@yandex.ru>]

On 28.09.2021 03:36, João Távora wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 28.09.2021 02:25, João Távora wrote:
>>
>> It's an example of a user trying to write a completion table (to be
>> consumed by company-capf, as they usually are)
> 
> Hm? A table is consumed by any capf-capable frontend. That's not limited
> to `company-capf'.

Right. But some frontend is required.

So the references to company-capf in that discussion are necessary, but 
incidental.

>> with sorting logic and tripping over the flex style overriding it.
> 
> But where is the "tripping" if, to the best of my knowledge (and given
> that you chose this specific Emacs bug), the complaint is about
> something that the flex style was designed to do from the very
> beginning?  That thing is sort, first and foremost, by how well the
> pattern entered by the user matches each candidate.  Doesn't this user
> like that?  If not, it's fine.  But not appreciating a behaviour doesn't
> count as "tripping over" to me.

Since we're talking about a beginner learning the c-a-p-f API, saying 
"it is intended to work this way" is rather off base. I think the 
question is rather which choice will ultimately lead to less friction.

While still leading to the expected behavior in all practical cases, of 
course.

>> You should read it (the last few messages will suffice).
> 
> I tried to, it's full of references to company internals that I can't
> evaluate.  Is the user writing a table specifically for company?  Or
> modifying company?  Or both?  I must understand it in terms of a simpler
> example.

They're asking how to write a completion table which does sorting.

It later turned out that they have the flex completion style set up in 
personal configuration. If you follow the discussion, you can note this 
conflict wasn't particularly easy to discover.

And the practice of asking for "full reproduction starting with emacs 
-Q" in such threads feels fairly out of place.

>> Having many similar-but-slightly-different styles available is
>> unlikely to reduce my support burdens.
> 
> But "reducing your support burdens" cannot come at the cost of breaking
> existing behaviour.  Look at the simple 5-line examples I gave to Omar
> (to which there was no reply, unfortunately).  I expect those examples
> to sort in a certain way, and I guess Omar would to like them some other
> way.

But would it? Break existing behavior in any scenario that matters?

Do we know of any completion table which specifies 
display-sort-function, where we're sure we want 'flex' to re-sort anyway?

> What is the problem with you telling those users to use 'pikachu'
> instead of 'flex'?  Or tell them to set a hypothetical variable
> flex-prefer-table-sorting to t?

Discovery.

> I also suggest that people: "if you're writing a completion table, make
> sure you try it without company as well".

Not something I'm eager to recommend to somebody just starting out. It 
wouldn't help here either, I believe.