[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new-flex-completion-style
From: |
João Távora |
Subject: |
Re: new-flex-completion-style |
Date: |
Wed, 13 Feb 2019 11:20:42 +0000 |
On Wed, Feb 13, 2019 at 12:29 AM Óscar Fuentes <address@hidden> wrote:
>
> João Távora <address@hidden> writes:
>
> > Óscar Fuentes <address@hidden> writes:
> >
> >> João Távora <address@hidden> writes:
> >
> >> Do you know flx [1] ? Would it be possible to implement it on top of
> >> your work by providing a score function and/or a sort function?
> >>
> >> 1. https://github.com/lewang/flx
> >
> > I remember looking at this a long time ago. It looked interesting, but
> > is almost certainly more complex/featureful than my implementation,
> > which is reasonably simple and tries to play along with the Emacs's
> > completion style/table/UI framework, something which is still relatively
> > fluid (as you can read in this thread). So I'd rather take it slowly
> > before adding new features.
> >
> > But I don't know what features you are looking for exactly, can you be
> > specific?
>
> Basically, flx takes an input string and a list of candidates, assigns
> an score to each candidate and returns a filtered list of candidates
> sorted by the score.
>
> This seems the same you described on your commit message.
Indeed. I just had a look again. The engine itself it around 360 loc
which should be 5-10x times longer than what I'm proposing. The
scoring itself seems quite more intricate, with special cases and
customization for word separators, a "heatmap", camel-case
exceptions, and probably some I haven't understood.
My implementation, on the other hand, takes advantage of the
existing emacs PCM mechanism to generate a
".*<letter>.*<anotherletter>.*" regex to do the matching.
Importantly, it's agnostic to the type of thing represented by
the string being matched. Scoring is hooked onto the existing
logic for char highlighting. The formula is a simple ad-hoc
thing that I invented and has been working OK. It's quotient of
a running sum of a function of distances that are known when
highlighting chars. Basically, it values "tighter" matches in
short strings, so matching "bar" to "obarb" scores higher than
matching it to "foobarbaz" which scores higher than
matching it to "booazzraa".
"Working OK" here means that the thing I meant is almost always
in the first three or four candidates. Perhaps you should try it
and confirm this, or show me cases where it isn't.
But you didn't answer my question: what specific features of flx
are you looking for? I'd be happy to implement them if I have
the time, but I have to understand what they are.
João
- new-flex-completion-style (was: [Emacs-diffs] scratch/ 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness), Stefan Monnier, 2019/02/11
- Re: new-flex-completion-style, João Távora, 2019/02/11
- Re: new-flex-completion-style, Óscar Fuentes, 2019/02/11
- Re: new-flex-completion-style, Stefan Monnier, 2019/02/13
- RE: new-flex-completion-style, Drew Adams, 2019/02/13
- Re: new-flex-completion-style, Óscar Fuentes, 2019/02/13
- Re: new-flex-completion-style, Daniel Pittman, 2019/02/13
Re: new-flex-completion-style, Stefan Monnier, 2019/02/12