RE: handling many matches [was: [ELPA] New package: transient]

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

> > 1. Progressive matching, i.e., narrowing the set
> >    of candidates by matching another pattern.
> > 2. Pruning, by excluding matches.
> 
> This is all high-maintenance. It requires the user to master the
> matching interface first, with extra keys and new behaviors.

No, it doesn't require anything special from users.
It's pretty natural.  One key to separate match
patterns.  Another to remove the last set of matches.
Any keys will do.  And no requirement to use either.

Some completion frameworks offer #1, using SPC or
comma as the key.  Icicles uses S-SPC, by default,
so SPC can self-insert as part of a candidate.

(I don't know of other frameworks that offer #2,
but perhaps there are some.)

> Whereas "other editors" have already solved this better (perhaps not
> ideally, but better) by doing fuzzy matching with smart enough sorting.
> We should start by matching that functionality, and only then add extra
> capabilities, maybe.

I disagree (as I said) that any fuzzy matching,
with or without scoring, "solves this", at all.
___


And for the record, Icicles also offers fuzzy
matching - 7 kinds, including some that use
scoring.

https://www.emacswiki.org/emacs/Icicles_-_Completion_Methods_and_Styles#FuzzyCompletion

This is not about touting Icicles.  But for some
perspective, the relative worth of fuzzy matching
compared to progressive matching (#1) and pruning
(#2) is maybe 1 to 100.  Icicles provides a space
to compare them.

Of course, it depends on the domain of candidates;
for some domains fuzzy matching can be quite
helpful.  But even then it's better to be able to
use more than one matching (fuzzy or not) and be
able to prune matches (fuzzy or not).  Being able
to do such things doesn't mean you're required to.

In sum, fuzzy matching is a red herring, here -
completely orthogonal to the point made.