Re: BIKESHED: completion faces

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Tue, 05 Nov 2019 21:43:42 +0000
> 
> > If we have one efficient way, why do we need to consider others?
> 
> Indeed we don't, you're totally right, not for the 'prefix/basic'
> completion.  However some people have made a point that there should be
> some kind of consistency at this level between completion styles, that
> the thing emphasized in 'prefix/basic' should have some semantic
> relation to the thing emphasized thing for 'flex' and 'substring' too.
> 
> So, to "please greeks and trojans" [1], an equally efficient AND
> cross-style-consistent style could be found, we could keep the "common"
> and "first-difference" face names, and 'flex' would ship without a
> default "crippling" (see below)..

Sorry, but I see no reason for any kind of "consistency" here.  We
need to highlight to help the user specify the right completion
candidate, all the rest is secondary IMO.

> >> One of them is to highlight the preceding character.
> >
> > ??? How does this help me to select what to type next?
> 
> Did you try the experiment I proposed (swap the two faces)?  I have no
> problem recognizing the character "to type next" when I do it.  See the
> attached gif another-way-to-see-the-first-difference.gif

I did try that, and it makes the task of finding the next character to
type much harder for me.

> > I don't see why it's important to explain how did the completion
> > algorithm arrive at a particular candidate.  The completion algorithm
> > is there to intuit what we mean in the most efficient way, but the
> > details of how it does that are immaterial.  The only ones who may be
> > interested are those who study completion algorithms ;-)
> 
> I may sound like a completion scholar to you, but you also sound like
> you haven't experimented with 'flex' for more than 1 second, otherwise
> you wouldn't be asking that question ;-)

There's no need to make such assumptions just because I happen to
disagree with something you consider self-evident.  I did play with
that long enough to make up my mind.

> So I attach another Emacs -Q gif, crippled-flex.gif, where you see
> the current problem, and yet another gif, useful-flex.gif, where the
> matching part is highlighted bold.

Thanks, but it doesn't change my mind.

> I think you will agree it's not a detail.  The reason we want to
> highlight matching parts in flex is the same reason grep and every
> search tool and search engine I know decides to highlight matching
> parts: to call attention to the part that matched.

Grep's goal is to find the match, so it makes sense to highlight that
match.  The goal here is quite different, so highlighting the match
makes much less sense in this context.

> Of course, fixing that crippled default state of 'flex' is a couple of
> customizations away (Put the common face to 'bold' and the
> first-difference to nothing).  But, IMHO, it would be a shame if we were
> to release Emacs 27 with this familar matching method and no good
> default faces to go with it.

If you are saying that the default face needs to be changed, it is a
completely different issue.  This thread AFAIU is mainly about
defining new faces that are put on other parts of the candidate
strings.  It is not about highlighting the same parts, but with
different colors or other attributes.

> > No, "first difference" is always the character to be typed after
> > point.  At least for the vastly important case that point is at the
> > end of what you typed, i.e. you don't move point back after typing
> > something.
> 
> But for the 'flex' case (among others more obscure) that first character
> "to be typed" -- presumably to narrow down the set further -- might be
> any character following 'point', for each completion, not just the one
> in the 'point+1' position.

So show all of them ,with the same face.  That's not what this thread
started with, AFAIU, it started with an assertion that
completion-first-difference is flawed as a concept, and should be
replaced with something new and different.

> Finally, I believe other UI's that have this kind of flex search (I
> think they are not rare at all nowadays, not just in editors) also use a
> prominent (often bold) face, to mark the common part.

That's a different issue.