[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: RE: handling many matches [was: [ELPA] New package: transient]
Date: Fri, 1 May 2020 15:47:46 -0700 (PDT)

> > 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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]