Re: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness

[João Távora]

Dmitry Gutov <address@hidden> writes:

> Consequently, a preexisting completion tables wouldn't be
> supported. But like I said, it shouldn't be hard to change either.

Oh.  That's what I feared (I think) It would be nice to add something
seemingly orthogonal like a "completion style" to all completion UI's
and all tables, without needing to change the completion tables
(granted, it would be good to *also* not change the UI's, but I'm not
sure there a solution for that).

> I dunno, sorting takes CPU time anyways. Not sure a combination of
> several sorting functions will frequently give a better result than
> just one of them.

I dunno what you dunno.  When using flex/scatter it's *really* important
to sort by flex-match.  I suggested "stable sorting" because it's a
slightly more decent thing to completion tables.  And by sorting twice
it's not like we're changing the Big-O complexity or anything.

But I also don't mind a scheme where the style's sorting completely
takes over (and we save those CPU cycles).

> But then, if you enable company-sort-by-occurrence via
> company-transformers, the completion style's sorting won't be visible
> anymore anyway.

I don't know what company-transformers are.  On the one hand I suppose
when you want to sort by occurance, you ... want to sort by occurrence.
So if you use the symbol "foofooubarbarnbazbazdquuxquuxo" very often
you'll see it sort to the top for your "undo" example.  So maybe company
should take the style's sorting last here, dunno.

> It's a question whether any other sorting approaches end up being
> helpful, but maybe some hybrid functions will work, where both
> occurrences and flex score are taken into account.

In this case I would first sort by occurance and then style-score.
There's no easy way to make a hybrid function, so we must pick a
default.  For all the examples I've been given, it seems that
flex-sorting should always come last. Since flex is the first and only
style that carries some sorting idea with it, perhaps it's not a very
bad idea to give it _some_ priority by default.

>> Eventually, we can add a keybinding to resort exclusively according to
>> the table or exclusively according to the completion style.
>
> In the approach I'm thinking of, both options are the same sorting
> function.

How would you synthetize it? 

> And still, seeing it wouldn't help me if I'm just writing code. Sorry
> for being blunt.

I'm a big boy, I can take blunt... :-)

> Sort by them, sure. But show the values to the user? Why?

In the general case, so the user has an idea _why_ something is being
automatically.  Humans generally gain confidence in algorithms if
they're shown human-comprehensible hints as to why it is is doing
something (humans generally also like this from other humans, which
explains why you ask me so many questions :-).

In this particular case, it's a very common idiom when displaying
tables/lists of something.  Perhaps in the "occurance sorting" field,
he/she will choose another word used less frequently for stylistic
purposes.

But, all that said, I'm not going to kill myself over the annotation,
nor do I think it even merits a customization option, though it's
probably not hard to do it anyway.

> The former, more or less. This creates a certain limitation, sure, but
> it shouldn't be a problem for Eglot.

Hmm? By far, Eglot isn't the only one thing I'm interested in enhancing
(actually, I've had few opportunities to actualy _use_ Eglot lately).

João