RE: VOTE: Changing completions-common-part face's default

[Drew Adams]

> As soon as flex/fuzzy/scatter became accessible and popular
> (because of  programming speed) they decided to use ways to
> highlight the matches,  very often boldface.  So it's not a
> "trend" at all. We should ask Drew who probably has had such
> system in place for a much longer time.

I can't speak to any trends.  Different kinds of
fuzzy matching have existed outside and inside Emacs
for a long time, in various 3rd-party libraries.

AFAIK, I (in Icicles) was the first to use such
kinds of matching for _completion_ - that's all.
That dates back to 2006 or before.

More generally, beyond various kinds of what is
sometimes called "fuzzy" matching, there are kinds
of matching other than basic, prefix-only matching -
substring matching, for example.  And some of those
were added to Emacs, including for completion, and
including fairly long ago, ultimately as
`completion-styles'.

"Fuzzy" matching can, if you like, include
so-called "flex" matching (Icicles calls this
"scatter matching").

The basic scatter match is a "poor man's fuzzy".
It just uses a simple regexp constructed from the
chars you type, by inserting `.*' between them -
typing `abc' uses regexp `a.*b.*c'.

What Icicles also provides "SPC scatter" matching,
which, IIUC, what is used by Ivy (but someone can
correct me).  It's like scatter matching, but it
matches the parts of your input that are separated
by SPC chars - it matches arbitrary text at the
separations between those parts.

On their own, such scatter matching does not
provide or use any scoring.  But some more-truly
"fuzzy" matches do sometimes provide scoring.

Icicles highlighting of matches is pretty simple.
It doesn't bother to try, for some kinds of fuzzy
matching.  For those that translate to using a
regexp, such as the scatter matches, highlighting
is trivial (`string-match-p').

I already spoke to the utility of highlighting the
matched part (plus, in the case of Icicles, the
part that is common to all matching completions).

I'll just add, since someone brought this up: it's
not about not trusting the matching algorithm.
It's not about checking by eyeball, to see if
there are matches shown that you don't think
really belong there.  Not at all.

It's, yes, partly that "fuzzy" etc. completion is
not always obvious; the results are not always
what one might expect.

But more importantly, it's just to provide you
_feedback on what you're doing_.  You're matching
input against a domain of possible candidates -
you're exploring that domain.  Visually connecting
what you do with what you get really does help.

And, since the contrary has been said several
times now in this thread, it's _not_ just about
figuring out what the next char you type should be.

The "next char you type" is only one way to
interact with the set of possible candidates and
the set of current matches.  Focusing on that's
based on thinking in terms of prefix matching,
choosing a single candidate, and immediately
exiting completion.

Besides the "next char you type", there's what
chars you might delete, and where, what chars
you might insert, and where - and many other
actions, which might have nothing to do with
editing your input.

When you can act in many different ways on
particular, or all, current matches, it really
helps to be able to distinguish them in terms
of which of their parts match the input pattern.

Dunno how to explain this more, briefly.  I'm
sure that those users who've used completion
setups that let you act on multiple candidates
or in multiple ways, or that let you match in
more complex (sometimes unclear) ways, get it.
For those who don't, I say play with it, and
you will.

FWIW, I'm _not_ a big proponent of fuzzy
matching.  I'm a big proponent of substring
and regexp matching.

What I use, myself, the vast majority of the
time, is regexp matching, which includes
substring matching.

But YMMV.  And Icicles does provide several
kinds of fuzzy matching.  This page describes
them:

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