[Top][All Lists]

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

Re: BIKESHED: completion faces

From: Dmitry Gutov
Subject: Re: BIKESHED: completion faces
Date: Tue, 5 Nov 2019 16:57:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 05.11.2019 13:10, 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.

The implication would be that trying to improve the defaults is useless or hopeless. I disagree.

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

Have you read my other idea, then?

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.

All can be improved, just with varying degrees of difficulty. But there are other techniques, like limiting the number of matches shown at a time. One just has to make sure not to cache the result improperly.

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

I'm trying it out with 'M-x completion-at-point'.

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.

As you can imagine, IMHO this part "making sense" is less important than the consistency in highlighting.

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

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.

I wouldn't use 'shadow' or 'bold' for the new face either. Nothing that matches completions-common-part of completions-first-difference exactly.

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

Here's an example. When the input is one char, how will you figure out what the highlighting in the *Completions* buffer means? Just by whether the character under the face is the same one? It's not reliable.

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

I've tried to implement my idea, but somehow the added highlighting gets eaten before the buffer is displayed. But the attached patch should illustrate it anyway.

Attachment: completions-nontrivial-common-part.diff
Description: Text Data

reply via email to

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