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

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.08.2021 17:05, João Távora wrote:
>> On Tue, Aug 17, 2021, 13:43 Dmitry Gutov <dgutov@yandex.ru
>> <mailto:dgutov@yandex.ru>> wrote:
>>     On 17.08.2021 13:41, João Távora wrote:
>>      > I've
>>      > not seen an example of a table where its original sorting
>>     mattered more
>>      > _when_  there is some search pattern.
>>     Do you have examples of completion tables which do specify
>> sorting, but
>>     where flex sorting obviously should take precedence?
>> No, do you? Love to see them, or the converse. But does it matter?
>> Flex is for searching with patterns, stable sorted by scores,
>> solving ties with whatever sort order came first. Dmitry/flex, or
>> Flix, or Flax, may be something else, you understand? It's by design
>> like this.
>
> If there aren't any such significant cases, flex could do what Omar is
> suggesting, solving the reported problem with no real downside.

OK. Let's see the code and then it's easier to evaluate if there's "no
real downside".  If it's indeed true, than no problem.

If it helps, I'll just repeat that flex is a pattern-matching scoreing
thing.  You type "foo" and if the first element is "fabrobazo" and the
last one is "foobarbaz", the last one will sort before the first.  A guy
who made something called "hotfuzz" which is the same principle,
apparently, even better I guess.  https://github.com/axelf4/hotfuzz.
Anyway, I'd like it to stay that way even if the table says "fabrobazo"
is more important than "foobarbaz".  When there's no flexy stuff
happening, that's fine, when flex kicks in, it takes over.

> I would admit it to be a hackish move, but no more so than the recent
> commit ab23fa4.

I must admit to tire easily of adjectives like "hackish", "improper",
"dirty", "faux" along with "not my cup of tee" and "there will be subtle
bugs" and judgements based on some vague principia.  These things matter
close to 0 to me.  I need to hear criticism in the form of "there's a
bug when I do xyz", "it becomes 123% slower", or "it duplicates x lines
of code found in lalaland.el".  That's really the only useful criticism
of my programs that I can address.

In this case ab23fa4, bug#49888 directly solves a pretty solid and very
well described bug report that pointed to a vacuum in the flex
completion style.  It reuses functions
`minibuffer--sort-by-length-alpha' and `minibuffer--sort-by-position'
that someone else wrote to maximize code reuse.  To concrete things: can
code reuse and abstractions be improved even further there?  I wanted
to, but there were the problems noted in the FIXME.  You're welcome to
fix those, if you can.  Sorting takes time and patternless flex became
somewhat slower, but it'll become much faster soon, hopefully.

> Having multiple similar styles is of course an option, but it comes
> with code duplication and associated inconveniences (how many such
> styles should Emacs include OOTB?).

Code duplication if you make duplicated.  If you don't make it
duplicated there won't be duplication.  Different styles already reuse
lots of code.  How many styles?  As many as you think are worth
including, I guess.

> That could be solved with some more general approach, like have both
> styles and completion tables return sorting scores (with documented
> possible values and meanings), and do the combined sorting somewhere
> in the layer above. Then the user could choose the combining strategy,
> configured separately.

Sure, I guess, let's see some code.  I trust you to make lots of good
code that generally solves problems well and cares about backward
compatibility.  So let's do that and lay off the vague rethoric, please.

João