Re: new-flex-completion-style

[João Távora]

On Wed, Feb 13, 2019 at 6:54 PM Stefan Monnier <address@hidden> wrote:

> Making sure I understand:
> - "counts the +++" will always return the length of the pattern, right?
>   So this is used just to normalize the result to ]0..1].
> - if the falloff constant is 0, the denominator is the number of places
>   where a "star" had to be added (plus one).  And if the falloff
>   constant is positive it prefers more insertions of shorter text
>   chunks over fewer insertions of longer text chunks, and if it's
>   negative it oddly prefers longer insertions over shorter ones.

Yes and Yes.  The length of the pattern but probably not as
calculated by (length pattern).

I don't think it's odd.  I call the former "scattered match"
and the latter a "tighter match".  For the particular way I
remember symbol names, files names, etc, it's probably a good
idea, since I can almost always remember a full word in the name.

But sure enough I've had it configured for "scattered match"
all along and I didn't know!

> > Anyway, what do you think?  Is this acceptable or so you have anything
> > better?
>
> Fine by me (tho maybe I wouldn't count the final "---", to more
> closely match [no pun intended] the usual prefix completion).

Maybe this should be configurable, but in general I don't
think staying close to prefix completion should be a
goal, since this is a completely different game.  IOW, valuing
a string ends/beginning differently makes little sense in flex.

> >>> +           (put-text-property
> >>> +            0 1 'completion-pcm-commonality-score
> >>> +            (/ score-numerator (* len (1+ score-denominator)) 1.0) str))
> >>
> >> This will signal an error when `str` is the empty string :-(
> >
> > Ooops, but that that happen?  Can an empty string be pcm-matched
> > by some pattern?  There's
>
> I think it can if the pattern is empty.  So maybe all those
> put/get-text-property are fine if you make sure this code is never even
> called when the pattern is empty.

OK, I'll figure something out.

> BTW, the patch below seems to improve the behavior (e.g. it lets
> `.../emacs/cfi TAB` complete to `.../emacs/config` as it should since
> all remaining matches also match "config").

cool!