Re: new-flex-completion-style

["João Távora" <joaotavora@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Not sure if it's related to icomplete.  Maybe the length-heuristic is
> just not good for buffer names.

Agreed. 

> I think this length heuristic also works reasonably well in several
> other circumstances (e.g. file names).

OK. Makes sense.  Just to be sure we're talking about
completion-all-sorted-completions, right?

> It seems like it would be a clear win (the buffer-list order is a much
> better heuristic than the length).

I'm so glad you're volunteering to do this ;-)

>>> Still, in a case such as lisp/ecomplete.el where the completion table
>>> provides its own sorting based on recent-usage-frequency, how should
>>> this sorting be combined with that of flex?  I can see arguments in
>>> favor of saying that the flex-weight should be ignored in favor of the
>>> usage-frequency.
>> ecomplete has its own UI in ecomplete-display-matches?
>
> It also offers a completion-table (which I use via
> a completion-at-point-function).

But I can use that table with another UI right?  Is that
completion-at-point-function in Emacs or in your config?

>> My view of the matter is: completion table provides its sorting which
>> _can_ be overriden by completion style's sorting which _can_ be
>> overriden by completion UI's sorting.  AFAIU this can be done by writing
>> comparison functions that return nil if the current sorting should be
>> agnostic to both elements.
>
> Writing the function is of course the easy part. 
> The problem is where/how to insert this function.

We have to decide on a good standard order/combination of sorting
functions.  If we decide that's not good enough for some cases we can go
for more indirections à la CL method combinations.  (wonder if
cl-generic has method combinations).

But this could very possibly be overdesigning at this point.

> Duh!  I meant to add some idiotic scolding about those typos but got
> side tracked by the annotations issue.  Sorry.  I promise to be more
> firm next time.

Since this makes fixing my dumb mistakes more fun, I hereby scold you
for your lack of scolding.

>> I don't see the problem fully,
> Hmm... I guess in the completion-style case, you could indeed look at
> all the returned completions to compute the max-length and do some
> right-alignment based on that.  For some reason, I feel like it'd be
> better done elsewhere, tho (e.g. maybe company would rather right-align
> based on the max-length of the *displayed* completions rather than
> based on the max-length of all the completions).

I'll think better about this once we sort out the sorting, which has
priority.

>> So to summarize, I propose to add (1) the fafa9ec commit introducing
>> flex completion and (2) a new commit extracted from 2c7577558 which adds
>> the flex scoring calculation to each match, but doesn't do anything with
>> it yet.  Deal?
>
> Fine by me.  I'd call the score property `completion-score` because
> I don't see any reason why it should be specific to the completion-style
> (you could even have `flex` combine its score with a `completion-score`
> property previously set by the completion-table, and then have the
> front end combine that with its own scoring).
>
> I think you can also make minibuffer-completion-help sort according to
> that `completion-score`.
>
> Regarding the code, see comments below.

I've pushed a new version fixing the problems you reported off-list.  I
did that _before_ reading this message.

I'll take a look at this new batch, do the obvious fixes.  But before
submitting anything sorting-related, I'd like Dmitry to show a patch for
his sorting idea on top of scratch/new-flex-completion-style, try it out
a bit and then report back here.

João