RE: new-flex-completion-style

[Drew Adams]

> >> > Can you see that some of the following predefined orders
> >> > might be advantageous in particular contexts/use cases?
> >> > Can you see that whether matching is scatter, regexp,
> >> > basic prefix, or others, any of the following can be
> >> > useful?
> >> No, I can't.
> > Seriously?
> 
> All the examples you give are non-specific to the completion-style used,
> whereas the `flx` scoring seems more directly related to the
> completion style.

The sort order that a user might want in any
given context can depend on any number of things.

Some completion styles might be context-related
(i.e., more suited to some kinds of completion,
e.g. file names, than to other kinds).  But for
the most part they are not.  Categories bring us
closer to use contexts/cases than styles, I guess.

But actually, I did mention two fuzzy-matching
methods that impose the sort order used - they
give you no other sort choice.  In particular,
they can't give you a sort order that is
especially useful for a certain context.

I don't see scatter-matching as limiting in
that way.  You can use it with the sort orders
I listed.  That's not the case for
`fuzzy-match.el' matching or Swank fuzzy symbol
matching.

> I guess one could consider `flx` scoring as just another kind of
> sorting, but I'm pretty sure that it can give odd results when used
> with (say) regexp-style completion.

Depends on the regexp.  But sure, you wouldn't
want to sort based on scoring that privileges
substring match length for input that is a wild
regexp.

FWIW, Icicles uses `flx' _only_ for sorting (by
`flx-score'), not for matching.  And yes, it's
just another sorting method.  I could have
included it in the list I showed.  And yes, it's
not context-specific (though it's likely more
useful with some contexts than with others).

> So maybe, another way to look at it is that there are several sorting
> choices, one of them being provided by the completion-style.

That goes back to my point about coupling such
things together (matching and sorting) versus
decoupling and so letting a user mix & match
(modulo the rare exception).

If a user specifies a particular sort order
in a completion style then s?he can't also
use the rest of that style without that sort
order, or vice versa - not without defining
additional completion styles that provide
those other possibilities.

Sure, allowing a style to include a sort can
be handy if you want to use that combination
a lot.  It can also be limiting.

Why didn't you just include categories, not
as separately specifiable, but only as part
of styles?

Surely you saw an advantage in being able to
mix & match.  Same thing applies to sorting,
in general (i.e. modulo some exceptions, as
mentioned).

Being able to include a sort order in a style
is one thing.  Having to do that, to be able
to choose a sort order, is another thing.