RE: new-flex-completion-style

[Drew Adams <drew.adams@oracle.com>]

> > 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?  You can't imagine that someone completing
buffer names might want to (sometimes) put more
recently used buffer names before others for better
visibility or for quicker cycling access?

You can't imagine anyone ever wanting a different
order of candidates than what you would define based
on match scores?

Match scores are tightly linked to sort order only
for certain kinds of matching.  And even then such
an ordering is typically "all other things being
equal", i.e., for lack of any more meaningful sort.

What you say sounds bizarre to me.  Different contexts
can call for different sort orders.  And different
commands provide different contexts, as do different
user preferences.

Take Info nodes for `g', for instance.  Can't you
imagine that sometimes you might want to see completion
matches in book order, and other times in order of the
dates of your past visits, and other times in order of
the number of your visits, and other times in
alphabetical order?

And even for, say, number of visits, can you imagine
that sometimes you want to visit nodes that you've
visited a lot, and other times you might want to visit
nodes that you've never visited?

Do you really feel that one size (one order) fits all?

> That's probably input for the style vs category vs table
> vs UI debate, where I'd rather, like Stefan, go for the path of
> least redesign which seems to plug sorting to a style.

My own opinion on that is that what's important is that
a user be able to control such things on the fly.  Sort
order, for example: be able to immediately change it by
hitting a key while completing.

AFAIK (I could be wrong; I don't bother following this
evolution), vanilla Emacs doesn't even give users a way
to change completion styles on the fly.  Adding a sort
order or a category or whatever else to a style definition
doesn't help if a user can't turn on a dime, switching
to a different style.

What's more: As long as accommodation is attempted by
_combining_ such (pretty independent) things: sort order,
match method, categories, users will lose.

Why?  Because even if you give them a way to quickly
switch styles they can't switch parts of a style.  With
3 axes (order, matching, category) and with, say, 4
choices per axis, that's a lot of possible combinations.

To allow a user to pick any of those combinations s?he'd
need a style for each combination!  And then s?he'd have
to be able to remember them all and keep track of them.

No, the right approach, I think, is to let users move
at will, fluidly, along any such axis, to get any
combination anytime.  All a user needs to remember in
that case is a key to choose something on a given axis.

But no, I'm not trying to design or redesign vanilla
Emacs completion.  I tried to communicate all of this
long ago, and several times.  No takers.  So be it.
Been there; done that.  (I have, however, seen several
of the ideas picked up by other completion systems:
Helm, Ivy, even Ido and Icomplete in some cases.)

> Perhaps I'll change my opinion with specific use cases where
> using my proposed sorting function with flex isn't a good
> solution.

You should be able to change from, or to, it on the fly,
when you find that useful.  Then, being a believer in
your thing, you would set it as your preferred default
behavior.  But you'd still be able to pop out of the
box when you felt like it, and _without_ customizing
some preference and then starting over.