RE: [External] : Re: Improvement proposals for `completing-read'

[Drew Adams]

> - There is this metadata adjustment which somehow unexpectedly
> adjusts/mutates the metadata
> - Why does a completion style sort? I am mostly happy with styles which
> don't do that. When I was working on my Consult package I was actually
> confused by the "disorder" introduced by `flex` and `fido-mode` even
> with `display/cycle-sort-function` set to the identity.

In most situations, sorting can and should be
separate from filtering, i.e., from determining
what the current set of candidates is.

However, some kinds of filtering naturally lend
themselves to some sort orders.  This is true of
certain kinds of "fuzzy" matching, for example.

Even in those cases it can sometimes make sense
for users to be able to turn off such "natural"
sorting or to impose another sort order.

In general (nearly always) it makes sense to
provide users with the ability to _choose_ a sort
order.  And preferably the ability to do that on
the fly, during completion/matching.

I don't know if another completion "system"
besides Icicles offers that possibility.  (Well,
I also offer it in my small `sortie.el', which
is based on what Icicles does for such sorting.)

I'm not aware of any, but I wouldn't be surprised,
and would be glad, if that feature too has been
picked by other completion frameworks.  IMO, it's
super-important to other things that "completion"
can offer.

In particular, choosing - or even seeing first -
candidates based on a given sort order makes a
huge difference in how you interact with the
overall set of candidates.

Some completion regimes, such as Ido, have even
hard-coded a sort order they suppose to be most
handy (based on use frequency or recency or some
such).  (Maybe Ido offers more possibilities now;
dunno.)

[FWIW, I've also never seen a good reason why
vanilla Emacs separates `display-sort-function'
and `cycle-sort-function'.  There's no doubt a
use case for using only one of them, or using
different functions for them, but I haven't
seen it.]

Vanilla Emacs does offer convenient access to
previous inputs, in reverse chronological order,
so at least that order has always been recognized
as useful.  But previous inputs matched by your
current pattern aren't sorted specially as
candidates (for cycle order or display order).

> I should probably read a bit up on the history of
> this feature, then I will know better. But when I
> first saw this flex adjustment I got confused.

[IMO, such fuzzy-match methods and attendant sort
orders have limited applicability for completion
contexts.  They're useful for some things, not
useful for most things.  Just one opinion.  And
yet, Icicles offers them.  It offers 7 kinds of
fuzzy matching, but only a few of them are coupled
with sort orders.]