[Top][All Lists]

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

RE: BIKESHED: completion faces

From: Drew Adams
Subject: RE: BIKESHED: completion faces
Date: Wed, 6 Nov 2019 13:40:41 -0800 (PST)

> > Completion is not just about choosing a completion
> > candidate - at least it _need not_ be only about
> > that. It's also about exploring a set - the set of
> > things that match your current input.
> Yes, but I don't see how highlighting what exactly matched is of any
> help in that case.  Especially with the weirdo matches some aggressive
> completion styles produce.  I care about the candidates and about how
> to narrow the list, not about how and why the completion picked up
> these particular candidates.

If you care about the set of candidates as a
whole, and are not just trying to "find the
one", or if you're interested in redefining
that set (including possibly narrowing it),
then "what exactly matched" your input can
be very helpful info.

Vanilla Emacs doesn't let you operate on the
set of matching candidates.  And it doesn't
update that set incrementally as you change
your input.  So your not appreciating the
value of what-parts-currently-match feedback
is understandable.

Maybe think about the fact that other UIs
have added similar such behavior, and it's
come up independently.  This wheel has been
discovered multiple times.

At least it was independent in the case of
Icicles, and I'm guessing the same was true
for at least one of VScode, Sublime, and Atom.

It's not (at least in the case of Icicles)
as if such highlighting was present at the
outset.  It came naturally out of using the
different kinds of matching - i.e., out of

With basic prefix matching, sure, the only
thing you need to look for, to understand
why you get the candidates you do, is the
matching prefix (hence "first difference").

With other kinds of matching it's not always
obvious why this and that are candidates.
Highlighting the parts that match helps.

But I don't imagine I can convince you.

> > Among other things, knowing what & how your input
> > matches can help you adjust it to match different
> > sets of candidates.
> That's what the "first difference" highlighting solves.

No, sorry, it doesn't.  And there's really no
special significance for "first difference".

> > Icicles highlights matches for your input with
> > different faces.  See attached screenshot.
> Sorry, I'm unconvinced.  I cannot think of a
> situation where such highlighting would help me.

Yes, I imagine you can't.  Sorry, but I don't
have the energy, time, or will to try to help
you with that.  Maybe someone else does (or not).

I think one key to understanding is to practice
with different ways of matching.  Another is to
think of operating on the set of matches.

Perhaps, with the latter for example, you can
guess how it can help to know whether all
candidates have a common match part and what
that part is.  Or not.

reply via email to

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