Re: BIKESHED: completion faces

[João Távora]

Dmitry Gutov <address@hidden> writes:
> On 05.11.2019 0:52, João Távora wrote:

> We agree, yes. Although I'm more in favor of changing the defaults,

So are we all, but that's a non-starter.  I'm sure everyone here thinks
"their" settings should be the defaults.

So what you are proposing with the "do-nothing" approach amounts to a
lose-lose.

> as soon as the kinks are worked out (e.g. flex is a bit slow when
> prefix is 1-2 chars).

You have to think about this "slowness".  A part of it might be
discovering if the 1-2 chars are in the potential match.  Another
different part of it might be due to the fact that the set of matches is
much greater when the pattern in short.

The former part can be improved in flex, the latter can't: it's
intrinsic to the technique.  But in matching systems like icomplete-mode
it isn't a problem (in terms of responsiveness) because icomplete-mode
has a while-no-input trick in it.  Perhaps so should company (presuming
that's what you are using).

>> So the next best thing is to add new functionality with a minimum of
>> customization necessary.  So, IMO, it's nonsensical to ask users to
>> customize the matching style to 'flex' AND also ask them customize a
>> face so that that more-than-familiar matching strategy reveals its
>> familiarity.
>
> I disagree that it's a significant problem, though. Enabling 'flex' is
> one line. Customizing the face is just another line.

Isn't true for custom.el users.  And it just doesn't make sense that to
enable "good" flex matching you have to go touch two places.  We're
discussing usability, after all.

>> This is better: I think this would lead you to my idea of a new
>> `completion-relevant` face, which we would set to bold or something very
>> prominent.  For the 'prefix' the relevant part is the "next character"
>> and for the 'flex' style is whatever has matched.
>> completions-first-difference could then be made an alias of that new
>> face.
>
> Hmm, I don't like this changing of terms, sorry. This way, the same
> highlighting would be applied to two fairly different things.

So is 'shadow' and 'bold' and many more.  It all has to do with how you
design the semantics, something that is our prerrogative.  The current
face semantics were designed for 'prefix', they just don't scale well
for other pattern-matching strategies.

What I'm proposing is no different from say, mode-line-emphasis, which
lisp/man.el and lisp/vc/vc-dispatcher.el use in "two wildly different
things".

Of course, another way out, at the expense of yet another face, is to
add completions-flex-emphasis or something like that.

João