[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
familiarity.
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
face.
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
'completion-relevant'.
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.
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/03
- Re: BIKESHED: completion faces, Stefan Monnier, 2019/11/03
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/04
- Re: BIKESHED: completion faces, Stefan Monnier, 2019/11/04
- Re: BIKESHED: completion faces, João Távora, 2019/11/04
- Re: BIKESHED: completion faces,
Dmitry Gutov <=
- Re: BIKESHED: completion faces, João Távora, 2019/11/05
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/05
- Re: BIKESHED: completion faces, Stefan Monnier, 2019/11/05
- Re: BIKESHED: completion faces, João Távora, 2019/11/05
- Re: BIKESHED: completion faces, Juri Linkov, 2019/11/05
- Re: BIKESHED: completion faces, Stefan Monnier, 2019/11/05
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/05
- Re: BIKESHED: completion faces, Stefan Monnier, 2019/11/05
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/06
- VOTE: Changing completions-common-part face's default, Stefan Monnier, 2019/11/06