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

[Dmitry Gutov]

On 12.02.2019 20:21, João Távora wrote:

> 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).

You have a point, sure. But I'd rather reuse the abstraction we already 
have as the first step, and then maybe extend it (or add a new one), 
rather add sorting code that uses these text properties to an existing 
function.

> 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.

Constants matter sometimes, too. Not necessarily in this case, but...

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

That would be ideal, I think.

> I don't know what company-transformers are.

Not too hard to find out, I think.

> 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.

OK, I was probably wrong here. Like, if only some of the completions 
have occurences, the rest would be sorted by flex scores, and that... 
sounds pretty good.

> 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.

You probably mean assign the least priority to flex's scores. The flex 
score sort would happen first with this approach, though.

Almost all completions will have different scores, so sorting by them 
last would make all the previous sorting disappear.

> > > 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?

Err, not the way you'd want. The table would just be designed to be used 
with the completion style. And so its sorting function.

> 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 :-).

For a little while, maybe. To obtain the said confidence. And then, I'd 
opt to turn it off, because I prefer to avoid too much visual clutter 
(one of the reasons to use Emacs).

> 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.

You see, regarding the annotations as well, it makes more sense to reuse 
the existing mechanism, or make it more flexible as well, somehow.

> > 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).

Sly's completion table could take the same approach. As long as the 
completion table is under your control, it's all good.

By the way, we could also add an indirection for display-sort-function 
(and maybe the -cycle- one as well) similar to the styles. So we not 
only assign a style (or several of them) based on the category, but also 
the sorting function. This way, sorting of buffers the right way would 
still work and make sense. And at the same time, the user could change 
certain categories to use both flex matching and flex score sorting.

That's more work for the user, but still. Seems kinda elegant.