[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: BIKESHED: completion faces
From: |
João Távora |
Subject: |
Re: BIKESHED: completion faces |
Date: |
Tue, 05 Nov 2019 21:43:42 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: João Távora <address@hidden>
>> Date: Tue, 5 Nov 2019 19:16:00 +0000
>> Cc: Stefan Monnier <address@hidden>, Dmitry Gutov <address@hidden>,
>> emacs-devel <address@hidden>
>>
>> > The purpose of completion-first-difference is to help the user decide
>> > what to type next.
>>
>> Indeed it does that. But there are equally efficient other ways to do the
>> same, in my opinion.
>
> 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)..
>> 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
another-way-to-see-the-first-difference.gif
Description: GIF image
(BTW I'm sorry I made a .gif and not a .png. Animation was not strictly
required here, but I don't know the keybindings to make simple
screenshots on this computer.)
>> > What is the purpose of highlighting other parts of
>> > the candidates?
>>
>> For a matching style such as flex or substring (as you would find in
>> many other editors) it's important to visually explain users to users
>> why certain strings that don't start with the pattern they entered
>> are being shown on the screen. I attach an image.
>
> 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 ;-) . 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.
crippled-flex.gif
Description: GIF image
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.
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.
useful-flex.gif
Description: GIF image
>> completion-first-difference is at the very least a misnomer for
>> other types of completion, because with flex there can be infinitely
>> many "first" differences.
> 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. If you use "flex" for a little while, you'll
soon see that this face (which, by default in Emacs, is the only "bold"
one of the two) is quite useless for 'flex'.
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. But, like Stefan,
I would like casual users of those other UI's to present the specifics.
João
[1]: Apparently an exclusively portuguese saying.
- Re: BIKESHED: completion faces, (continued)
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, Stefan Monnier, 2019/11/05
- Re: BIKESHED: completion faces, Stefan Monnier, 2019/11/05
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/05
- Re: BIKESHED: completion faces, João Távora, 2019/11/05
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/05
- Re: BIKESHED: completion faces,
João Távora <=
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, Ergus, 2019/11/06
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/07
- Re: BIKESHED: completion faces, João Távora, 2019/11/07
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/07