[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score,

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness
Date: Wed, 13 Feb 2019 02:47:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]