BIKESHED: completion faces

classic Classic list List threaded Threaded
166 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

BIKESHED: completion faces

Stefan Monnier
In Emacs-26, completion faces looked like the following:

- the "common" part shown like the default face.
- the "first-difference" shown in bold.
- everything else uses the default face.

The "common" part is the part applied to the characters that are also
found in the current minibuffer.  E.g. when completing

   M-x ne-li ?

the "ne" and "-li" chars in the *Completions* are the "common" part.

With the basic, prefix completion, the "common" part is not very
important and is separated from the rest at the "first-difference", so
the default faces make a fair bit of sense there.

But for other completion styles such as `substring`,
`partial-completion`, and even more so for `flex`, it's not always
immediately obvious how the minibuffer contents relate to the possible
completions displayed in *Completions*.

For this reason, it is common in other completion systems to
highlight the "common" part somehow (e.g. underline, bold, ...).

I think Emacs's defaults should be changed so that the "common" part
(which uses the `completions-common-part` face) is highlighted somehow.

So, what should we go for:
- bold (but then we need to change the `completions-first-difference`
  face to keep it different, e.g. underlined)?
- underlined (tho I don't like underlined text very much)?
- some foreground color?
- some background color?
- something else?


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

João Távora
Stefan Monnier <[hidden email]> writes:

> For this reason, it is common in other completion systems to
> highlight the "common" part somehow (e.g. underline, bold, ...).
>
> So, what should we go for:
> - bold (but then we need to change the `completions-first-difference`
>   face to keep it different, e.g. underlined)?

+1 for this option.  Tho any option that uses a prominent face for the
"common" part is good.

João

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Juri Linkov-2
In reply to this post by Stefan Monnier
> So, what should we go for:
> - bold (but then we need to change the `completions-first-difference`
>   face to keep it different, e.g. underlined)?

bold in completions-first-difference helps to immediately see the
next character to type to narrow completions further.

> - underlined (tho I don't like underlined text very much)?
> - some foreground color?

For several years I've been using completions-common-part
inherited from the 'shadow' face, and it works pretty well
for this purpose.

> - some background color?
> - something else?

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

João Távora
Juri Linkov <[hidden email]> writes:

> bold in completions-first-difference helps to immediately see the
> next character to type to narrow completions further.

<mild bikeshedding starts>

Yes, but some questions, Juri:

* wouldn't any other face, say "underline", serve the same purpose?

* would you not be equally and efficiently informed of such facts if
  completions-common-part were _more_ prominent and
  completions-first-difference was _less_ prominent?

* In completion styles other than "basic", there are many other
  characters, besides the one marked with completions-first-difference,
  that you type to narrow completion further, right?

>> - underlined (tho I don't like underlined text very much)?
>> - some foreground color?
> For several years I've been using completions-common-part
> inherited from the 'shadow' face, and it works pretty well
> for this purpose.

Do you use mainly the "basic" completion style? I.e. do you customize
"completion-styles"?

Thanks,
João


Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Juri Linkov-2
>> bold in completions-first-difference helps to immediately see the
>> next character to type to narrow completions further.
>
> <mild bikeshedding starts>
>
> Yes, but some questions, Juri:
>
> * wouldn't any other face, say "underline", serve the same purpose?

underline is less noticeable than bold, when used on a single character
with completions-first-difference in the "basic" completion style.

> * would you not be equally and efficiently informed of such facts if
>   completions-common-part were _more_ prominent and
>   completions-first-difference was _less_ prominent?

In the "basic" completion style completions-first-difference
needs to be more prominent since it's more important to indicate
the next character to type.

> * In completion styles other than "basic", there are many other
>   characters, besides the one marked with completions-first-difference,
>   that you type to narrow completion further, right?

Other completion styles don't highlight completions-first-difference
at all.  I'm not sure if only the "basic" completion style highlights
completions-first-difference.

Is it possible to use bold for completions-first-difference only
in the "basic" completion style, but for other completion styles
to use bold for completions-common-part?

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

João Távora
On Mon, Oct 28, 2019 at 11:01 PM Juri Linkov <[hidden email]> wrote:

>
> >> bold in completions-first-difference helps to immediately see the
> >> next character to type to narrow completions further.
> >
> > <mild bikeshedding starts>
> >
> > Yes, but some questions, Juri:
> >
> > * wouldn't any other face, say "underline", serve the same purpose?
>
> underline is less noticeable than bold, when used on a single character
> with completions-first-difference in the "basic" completion style.

> > * would you not be equally and efficiently informed of such facts if
> >   completions-common-part were _more_ prominent and
> >   completions-first-difference was _less_ prominent?
>
> In the "basic" completion style completions-first-difference
> needs to be more prominent since it's more important to indicate
> the next character to type.

I understand. But if completion-common-part is super-prominent, you get
more or less the same, right?  It's also very easy to see the "next" character
to type.

> Other completion styles don't highlight completions-first-difference
> at all.  I'm not sure if only the "basic" completion style highlights
> completions-first-difference.

Eh.  I removed it recently, without asking anyone, waiting for
someone to complain. :-)

Are you complaining? :-)  If you are, I'll revert that bit. If you aren't
I probably should revert it too...

Anyway, I don't think it makes a lot of sense in those styles,
unless you are editing inside the completion string,
which is relatively rare.

> Is it possible to use bold for completions-first-difference only
> in the "basic" completion style, but for other completion styles
> to use bold for completions-common-part?

That would make some sense, yes.  Perhaps we just need better names
for the faces. Perhaps a new alias "completion-important-bits-for-style"
for the current completion-first-difference would do fine.  We probably
need a better name, tho... "completion-style-hint"? "completion-emphasis"?

João
Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Stefan Monnier
In reply to this post by Juri Linkov-2
>>> bold in completions-first-difference helps to immediately see the
>>> next character to type to narrow completions further.
>> <mild bikeshedding starts>
>> Yes, but some questions, Juri:
>> * wouldn't any other face, say "underline", serve the same purpose?
> underline is less noticeable than bold, when used on a single character
> with completions-first-difference in the "basic" completion style.

I kind of like the underline for first-difference because it is similar
to the underline used in some toolkit's menus to indicate which
key-shortcut to use to select this entry.

>> * In completion styles other than "basic", there are many other
>>   characters, besides the one marked with completions-first-difference,
>>   that you type to narrow completion further, right?
> Other completion styles don't highlight completions-first-difference
> at all.

Apparently it's now the case on `master` but it's a (hopefully
temporary) regression: it definitely worked for `substring` and
`partial-completion` (and I see no reason why it can't work for
`flex` as well) and it makes just as much sense there as for
`basic` completion, if you ask me.

I think it's the `completion-common-part` highlighting which is
influenced by the completion style: its highlighting is much less
important/useful for `basic` completion and than for more complex
completion styles.

> Is it possible to use bold for completions-first-difference only
> in the "basic" completion style, but for other completion styles
> to use bold for completions-common-part?

I don't think we could/should make the faces's aspect depend on the
completion style used.  But the `basic` completion style could use
different faces than `substring`, `flex`, `initials`, and
`partial-completion`, yes.

This said, since the default completion uses sometimes `basic` and
sometimes `partial-completion`, I think it would be odd to have the
*Completions* use different highlighting on a case-by-case basis.


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Juri Linkov-2
In reply to this post by João Távora
>> Other completion styles don't highlight completions-first-difference
>> at all.  I'm not sure if only the "basic" completion style highlights
>> completions-first-difference.
>
> Eh.  I removed it recently, without asking anyone, waiting for
> someone to complain. :-)
>
> Are you complaining? :-)  If you are, I'll revert that bit. If you aren't
> I probably should revert it too...

No, I'm not complaining.  Wait for real complaints from someone
who will really get angry at your changes.  Or you could revert
preemptively to avoid such angry complaints. :-)

Or implement a solution that satisfies everyone: since in completion
styles other than "basic", there are many characters that you can type
to narrow completion further, is it possible to mark all them with
completions-first-difference?

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Juri Linkov-2
In reply to this post by Stefan Monnier
>>>> bold in completions-first-difference helps to immediately see the
>>>> next character to type to narrow completions further.
>>> <mild bikeshedding starts>
>>> Yes, but some questions, Juri:
>>> * wouldn't any other face, say "underline", serve the same purpose?
>> underline is less noticeable than bold, when used on a single character
>> with completions-first-difference in the "basic" completion style.
>
> I kind of like the underline for first-difference because it is similar
> to the underline used in some toolkit's menus to indicate which
> key-shortcut to use to select this entry.

Key-shortcuts in menus is a good analogy.  So underline for
completions-first-difference, and bold for completions-common-part
would look really nice.

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Dmitry Gutov
In reply to this post by Juri Linkov-2
On 29.10.2019 23:53, Juri Linkov wrote:
> Or implement a solution that satisfies everyone: since in completion
> styles other than "basic", there are many characters that you can type
> to narrow completion further, is it possible to mark all them with
> completions-first-difference?

I don't think it's a great idea. The -first-difference face serves a
good purpose: showing the most optimal character to type, to narrow down
the results as much as possible while retaining the given completion.

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

João Távora
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> writes:

>>> Other completion styles don't highlight completions-first-difference
>>> at all.  I'm not sure if only the "basic" completion style highlights
>>> completions-first-difference.
>>
>> Eh.  I removed it recently, without asking anyone, waiting for
>> someone to complain. :-)
>>
>> Are you complaining? :-)  If you are, I'll revert that bit. If you aren't
>> I probably should revert it too...
>
> No, I'm not complaining.  Wait for real complaints from someone
> who will really get angry at your changes.  Or you could revert
> preemptively to avoid such angry complaints. :-)

Yes, probably a good idea.  

> Or implement a solution that satisfies everyone: since in completion
> styles other than "basic", there are many characters that you can type
> to narrow completion further, is it possible to mark all them with
> completions-first-difference?

Yes, but no.  In the flex style, every character besides the one you've
already entered will potentially narrow the completion further.  So
you'd be left with a negative image than what we want.  Do I explain
myself.

And "what we want" is for it to work more like Company, Helm, or other
editors and UI's out there in the wild: show prominently the places in
the candidate where the pattern matches.

João



Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

João Távora
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> writes:

>>>>> bold in completions-first-difference helps to immediately see the
>>>>> next character to type to narrow completions further.
>>>> <mild bikeshedding starts>
>>>> Yes, but some questions, Juri:
>>>> * wouldn't any other face, say "underline", serve the same purpose?
>>> underline is less noticeable than bold, when used on a single character
>>> with completions-first-difference in the "basic" completion style.
>>
>> I kind of like the underline for first-difference because it is similar
>> to the underline used in some toolkit's menus to indicate which
>> key-shortcut to use to select this entry.
>
> Key-shortcuts in menus is a good analogy.  So underline for
> completions-first-difference, and bold for completions-common-part
> would look really nice.

Well that's exactly what Stefan is proposing.  OMG two bikesheds of the
same color: the Arthur Jackson award at last!

João

PS: Three sheds actually, I'm +1 on this too.

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Dmitry Gutov
In reply to this post by Stefan Monnier
On 27.10.2019 3:58, Stefan Monnier wrote:

> In Emacs-26, completion faces looked like the following:
>
> - the "common" part shown like the default face.
> - the "first-difference" shown in bold.
> - everything else uses the default face.
>
> The "common" part is the part applied to the characters that are also
> found in the current minibuffer.  E.g. when completing
>
>     M-x ne-li ?
>
> the "ne" and "-li" chars in the *Completions* are the "common" part.
>
> With the basic, prefix completion, the "common" part is not very
> important and is separated from the rest at the "first-difference", so
> the default faces make a fair bit of sense there.
>
> But for other completion styles such as `substring`,
> `partial-completion`, and even more so for `flex`, it's not always
> immediately obvious how the minibuffer contents relate to the possible
> completions displayed in *Completions*.

I wonder if it's *that* important, to be able to see the matching chars.

The -first-difference face shows actionable info: the next character to
type, to narrow down the completions list as much as possible while
ensuring that a given completion is still in. You could type other
chars, but the likelihood of ending up with several options (and no more
characters to type) will be higher.

So IMHO we could do nothing, and it will be a valid choice. As long as
all completion styles highlight completion-first-difference properly.

Furthermore, the position of -first-difference also hints at what
characters were matched (definitely ones before it).

> For this reason, it is common in other completion systems to
> highlight the "common" part somehow (e.g. underline, bold, ...).

Personally, I'm not a big fan of underline, italic and even bold (unless
it's used sparingly, like it is now). With that said...

> I think Emacs's defaults should be changed so that the "common" part
> (which uses the `completions-common-part` face) is highlighted somehow.
>
> So, what should we go for:
> - bold (but then we need to change the `completions-first-difference`
>    face to keep it different, e.g. underlined)?

If we end up doing this, we might as well change
completions-first-difference to be indistinguishable from 'default'.
Because the common part, when highlighted, duplicates the information.
The "first difference" character is simply the one after the last
segment of the common part, isn't it?

> - underlined (tho I don't like underlined text very much)?
> - some foreground color?
> - some background color?
> - something else?

If we do end up highlighting completions-common-part somehow, I vote for
background color, some very subtle one. Because using bold is going to
be annoying with prefix-based styles, and I don't think we can/should
use different methods for different styles.

Using "white smoke" seems okay with the default theme, as well as with
the light-background theme I'm using. No idea what color would be good
with dark-background themes.

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Stefan Monnier
> I wonder if it's *that* important, to be able to see the matching chars.

It has an explanatory value which makes the completion-style more
understandable (e.g. I'm pretty sure there are still users who don't
know about the `partial-completion` style that's enabled by default:
they just occasionally see completion lists which they don't understand
and shrug it off).

But no, I don't know how important it is (I do find it useful when
implementing/debugging the code to make sure it worked right ;-)

This said, it seems that highlighting the common part is the "standard"
behavior is all other completion systems whereas highlighting the "first
difference" seems to be specific to Emacs.

>> For this reason, it is common in other completion systems to
>> highlight the "common" part somehow (e.g. underline, bold, ...).
> Personally, I'm not a big fan of underline, italic and even bold (unless
> it's used sparingly, like it is now). With that said...

FWIW, I'm no big fan of underline (maybe it's the LaTeX influence speaking).
But I found it tolerable for first-difference after trying it out.


        Stefan


> The -first-difference face shows actionable info: the next character
> to type, to narrow down the completions list as much as possible while
> ensuring that a given completion is still in.
[...]
> Furthermore, the position of -first-difference also hints at what
> characters were matched (definitely ones before it).
[...]
> The "first difference" character is simply the one after the last
> segment of the common part, isn't it?

Agreed.

This is largely irrelevant for the choice of bikeshed color, but
I figure it's as a good a time as any to clarify that the above, while
largely true is not quite right either:

It's a bit more subtle than that (and the "first-difference" name is
a misnomer, due to history): when I revamped the default completion
system for Emacs-24, adding partial-completion (as well as `basic` which
is a bit more sophisticated than just "prefix completion", in reality),
I had to decide what to do with "first-difference" since it doesn't have
as clear a meaning as for the plain old prefix completion.  So the way
I adapted it to the new reality is that "first difference" now really
means "first char after point".  If you do

    M-x dovi C-b C-b ?

you'll see that `completions-first-difference` is applied to the "c"
of the "doc-view..." commands because that's the first character after
the position in the candidate that corresponds to the position of
point in the pattern.

So strictly speaking:
- No, there can also be common-part characters after first-difference
- Also, it's not always the case that the "first-difference" character
  is "the next character to type, to narrow down the completions list
  as much as possible while ensuring that a given completion is still
  in".  Two reasons for that:
  1- the "first-difference" character may already be part of the
     "common part".  E.g. `M-x revert C-b ?` will show the `t` with
     both `completions-first-difference` and `completion-common-part`
     and typing `t` will actually end up with a pattern that doesn't
     match anything.
  2- depending on the completion style, there might be further
     character that still keep the desired completion while
     eliminating more of the others.
     For example let's say you want to run
     `doc-view-fit-height-to-window`; after you do `M-x doc-view- ?`
     you'll see that the `f` is highlighted as first-difference
     but if hit `f` you still have 5 remaining choices, whereas if you
     hit `h` your choice is the only remaining one.

But by and large, these are exceptions.  Point (2) above is a bit more
true for `flex`, but I don't think it matters very much anyway.


Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Dmitry Gutov
On 30.10.2019 3:49, Stefan Monnier wrote:

> It has an explanatory value which makes the completion-style more
> understandable (e.g. I'm pretty sure there are still users who don't
> know about the `partial-completion` style that's enabled by default:
> they just occasionally see completion lists which they don't understand
> and shrug it off).

And just use it, probably. Even if they don't exactly see what matches what.

> But no, I don't know how important it is (I do find it useful when
> implementing/debugging the code to make sure it worked right ;-)

Indeed, but that's covered by your ability to customize the face anyway.

> This said, it seems that highlighting the common part is the "standard"
> behavior is all other completion systems whereas highlighting the "first
> difference" seems to be specific to Emacs.

Probably, but "all other completion systems" use a popup, which is a
significantly different UI. They usually have some different background
for that rectangle, and a different foreground as well. So there's some
pre-existing theming/styling work there.

Further, none of the other systems AFAIK use a fallback list of
completion styles. So normally the matching is fuzzy to begin with, and
in that case, highlighting the matches is moderately useful.

They won't see a situation with a long list of simple prefix matches
where the first column is highlighted uniformly.

>>> For this reason, it is common in other completion systems to
>>> highlight the "common" part somehow (e.g. underline, bold, ...).
>> Personally, I'm not a big fan of underline, italic and even bold (unless
>> it's used sparingly, like it is now). With that said...
>
> FWIW, I'm no big fan of underline (maybe it's the LaTeX influence speaking).
> But I found it tolerable for first-difference after trying it out.

I'm more against using bold for the common part. Underline is less
aggravating.

> It's a bit more subtle than that (and the "first-difference" name is
> a misnomer, due to history): when I revamped the default completion
> system for Emacs-24, adding partial-completion (as well as `basic` which
> is a bit more sophisticated than just "prefix completion", in reality),
> I had to decide what to do with "first-difference" since it doesn't have
> as clear a meaning as for the plain old prefix completion.  So the way
> I adapted it to the new reality is that "first difference" now really
> means "first char after point".  If you do
>
>      M-x dovi C-b C-b ?
>
> you'll see that `completions-first-difference` is applied to the "c"
> of the "doc-view..." commands because that's the first character after
> the position in the candidate that corresponds to the position of
> point in the pattern.

I'm having trouble reproducing this. Should I be using icomplete-mode?
Anyway, it bold-s the whole current selected completion.

And if I type "(dovi" in an Elisp buffer, C-M-i moves point to after the
common part.

So I get what you're hinting at, in theory, but these cases should
indeed be rare. And there might be other things we could do about them.

>    2- depending on the completion style, there might be further
>       character that still keep the desired completion while
>       eliminating more of the others.
>       For example let's say you want to run
>       `doc-view-fit-height-to-window`; after you do `M-x doc-view- ?`
>       you'll see that the `f` is highlighted as first-difference
>       but if hit `f` you still have 5 remaining choices, whereas if you
>       hit `h` your choice is the only remaining one.

This one in interesting. Some pre-computation could give a better hint
in this regard, but it could be disorienting as well, if one is used for
first-difference to be the char after point.

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Stefan Monnier
> Further, none of the other systems AFAIK use a fallback list of completion
> styles. So normally the matching is fuzzy to begin with, and in that case,
> highlighting the matches is moderately useful.
>
> They won't see a situation with a long list of simple prefix matches where
> the first column is highlighted uniformly.

Indeed, part of the issue is the difference between something like
`basic` and something like `flex`: in `basic` the
completions-common-part is not terribly interesting, whereas in `flex`
it's much more so.

We could use different faces in those two cases, but I feel like it
would be better if we can find a default that works well in both cases.

> I'm more against using bold for the common part. Underline is
> less aggravating.

Hmm... sadly, I find underlying the completions-common-part to be pretty
awful.  So it looks like both bold and underline are out?
Should we look for colors (background? foreground?)?

>>      M-x dovi C-b C-b ?
>> you'll see that `completions-first-difference` is applied to the "c"
>> of the "doc-view..." commands because that's the first character after
>> the position in the candidate that corresponds to the position of
>> point in the pattern.
>
> I'm having trouble reproducing this. Should I be using icomplete-mode?

No, just `emacs -Q` and then `M-x dovi C-b C-b ?`

> So I get what you're hinting at, in theory, but these cases should indeed be
> rare. And there might be other things we could do about them.

Agreed, I was just pointing out some corner-case behavior.  It's of no
consequence for the current discussion.


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Dmitry Gutov
On 04.11.2019 1:30, Stefan Monnier wrote:

> Indeed, part of the issue is the difference between something like
> `basic` and something like `flex`: in `basic` the
> completions-common-part is not terribly interesting, whereas in `flex`
> it's much more so.
>
> We could use different faces in those two cases, but I feel like it
> would be better if we can find a default that works well in both cases.

I concur.

>> I'm more against using bold for the common part. Underline is
>> less aggravating.
>
> Hmm... sadly, I find underlying the completions-common-part to be pretty
> awful.  So it looks like both bold and underline are out?
> Should we look for colors (background? foreground?)?

As suggested previously, a light-grey background might work. Or a dark
foreground.

IOW, either

   (set-face-foreground 'completions-common-part "blue3")

or

   (set-face-background 'completions-common-part "white smoke")

But neither seems optimal for prefix completion still.

Some other ideas:

- No nothing, on the reasoning that 'flex' is not in 'completion-styles'
by default. And many users who would add it there would probably use it
exclusively, and could thus customize their completions-common-part face
to be more informative, to their satisfaction. This suggestion could be
in the docs somewhere, maybe in the NEWS section that introduces 'flex'.

- Define a new face that would be applied by callers of
completion-all-completions to those completions where the equation
"common part == the whole part of the string before the char highlighted
by first-difference" doesn't hold true. So all uses of this face would
be informative. Although some absences of it might stand out (where a
flex match is a strict-prefix one). That face would have a distinct
background or foreground.

>>>       M-x dovi C-b C-b ?
>>> you'll see that `completions-first-difference` is applied to the "c"
>>> of the "doc-view..." commands because that's the first character after
>>> the position in the candidate that corresponds to the position of
>>> point in the pattern.
>>
>> I'm having trouble reproducing this. Should I be using icomplete-mode?
>
> No, just `emacs -Q` and then `M-x dovi C-b C-b ?`

OK, thank you. I see it now. Normally one would press TAB, not '?', though.

Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Stefan Monnier
>>> I'm having trouble reproducing this. Should I be using icomplete-mode?
>> No, just `emacs -Q` and then `M-x dovi C-b C-b ?`
> OK, thank you. I see it now. Normally one would press TAB, not '?', though.

Yes, but ? gives more control over the pattern (with TAB the pattern
has to be "already fully expanded" in order to get a list of
completions), so it's more work to find a good example ;-)


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

João Távora
In reply to this post by Dmitry Gutov
Dmitry Gutov <[hidden email]> writes:

> Some other ideas:
>
> - No nothing, on the reasoning that 'flex' is not in
>   'completion-styles' by default. And many users who would add it
>  there would probably use it exclusively, and could thus customize
> their completions-common-part face to be more informative, to their
> satisfaction. This suggestion could be in the docs somewhere, maybe in
> the NEWS section that introduces 'flex'.

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.

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.

> - Define a new face that would be applied by callers of
>   completion-all-completions to those completions where the equation
> "common part == the whole part of the string before the char
> highlighted by first-difference" doesn't hold true. So all uses of
> this face would be informative. Although some absences of it might
> stand out (where a flex match is a strict-prefix one). That face would
> have a distinct background or foreground.

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.

So my idea is:

1.  New 'completion-relevant' face, defaulting to the current
completions-first-difference value, used for emphasizing the relevant
parts of a completion.  Also alias the exiting
'completions-first-difference' to this new face.

2.  New 'completion-shadow' face, defaulting to the current
'completions-common-part' values, used for marking "seconday" parts of
completions .  Also alias the existing 'completions-common-part' face to
this new face.

Instead of 'completion-shadow', we could also call this
'completion-auxiliary' or something like that.

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

João



Reply | Threaded
Open this post in threaded view
|

Re: BIKESHED: completion faces

Dmitry Gutov
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.

1234 ... 9