[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 01:25:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 05.11.2019 0:52, João Távora wrote:

I don't agree with this reasoning at all.  First I think we agree Emacs
would profit (in influx from users) from defaults that make it behave
less like 90's Emacs and more like other younger editors.  However we
also know that we can't just change the defaults without bothering
users already relying on those defaults.

We agree, yes. Although I'm more in favor of changing the defaults, as soon as the kinks are worked out (e.g. flex is a bit slow when prefix is 1-2 chars).

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

I disagree that it's a significant problem, though. Enabling 'flex' is one line. Customizing the face is just another line.

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.

3. Completion styles decide which parts which faces to apply and when.
Prefix uses both like it does now.  Flex should probably only use

With my proposal, the positions of the new face can be unambiguously determined by the current markings. So its application doesn't need to be implemented in completion styles. It can be done in one place: the code rendering the *Completions* buffer.

reply via email to

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