bug#4911: mouse-face property should merge face attributes, not replace

[Clément Pit-Claudel]

Hi Drew,

Thanks for your reply!

On 25/04/2020 18.13, Drew Adams wrote:
>> I hadn't seen Drew's earlier reply when I reopened the bug report, so
>> here is a reply to Drew's message:
>>
>> Drew asked:
>>> It's easy enough to move the mouse, to see the non-hover face.  
>>> Why would one suppose that someone wants to merge that face with
>>> `mouse-face'?
>>
>> There's no need to suppose: users complained.
> 
> What were the complaints, exactly?

Users complained that hovering over links was causing syntax highlighting to 
disappear.  We were hoping to just change the background, or add a link, to the 
text to indicate that it was clickable, but that caused all of it to lose its 
syntax highlighting.

>> But to some extent it makes sense, since that's how links behave on the
>> web (merging faces), so it's hart to fault users for having the same
>> expectation in Emacs.
> 
> Really?  A mouseover action over a link in a web browser
> doesn't change the link appearance, by default.

Most websites do, I think (I just checked Google, the New York Times, and 
gnu.org), but you're right that the default style sheet doesn't include a face 
change..

> But (the equivalent of Emacs) face-merging?  How common
> is that, really?  So common that users expect that?  I
> don't think I've come across it.  I'm not aware of
> anything like Emacs face merging.

It's always the case: that's how CSS works.  Properties applied on hover stack 
with properties applied otherwise.
To fully replace the underlying face, you would have to make explicit all 
attributes of the mouseover face.

>>> Just what is the motivation, besides someone feeling the behavior is
>>> "ugly"?
>>
>> The motivation for the original report was that our users were
>> complaining to the PG, so it *was* in fact just "'omeone feeling the
>> behavior is "ugly"'.
> 
> What's "the PG"?

I meant "the PG team", sorry. PG is Proof General.

> The one case where I might want something like what
> you propose (or maybe exactly like it, depending on
> just what it is), would be when mouseover essentially
> underlines (or overlines or otherwise doesn't
> obscure) the text.  In that case, I can see a value
> to continuing to show the foreground colors of the
> underlined text - if that's realizable.

Yes yes yes!  We are in violent agreement here :)

>> As a concrete example, when I use M-x compile, for example, each error
>> and warning is highlighted.  Hovering with the mouse over an error
>> removes the highlighting.  Why is that helpful?
> 
> It can perhaps be easier to see the extent of the
> link?  Easier to notice the link?  Dunno.

With the change of background, it's actually quite readable.

> Anyway, I agree that it's helpful to keep face
> highlighting is some cases - in particular when,
> say, an entire line of code is highlighted.
> The effect of, say, `hl-line-mode' is what I
> prefer in a case like that - and yes, that's
> merging. Similarly, for the region.  I think
> it's less likely to be useful for links (i.e.,
> for mouseover).  But I could be wrong.

Yup, I feel just the same about hl-line-mode and the region.  I find the effect 
of foreground colors being reset when the background changes due to hovering 
quite distracting, but I agree there's personal taste involved.

> It's fine to provide a way (some other way - e.g.
> via a variable or another property or whatever)
> to have mouseover merge a face instead of imposing
> it.

Yes, I think all your suggestions are good approaches.
>> Also, I noticed that Eli wrote:
>>
>>> The use case described in the bug
>>> report could be handled by using some non-color attribute for the
>>> mouse-face, for example.
>>
>> The original report said that "Users complain that when the mouse is
>> over a region the normal fontification is obliterated."; why would it
>> help to use a non-color attribute?  The normal fontification would
>> still be obliterated.
> 
> Maybe Eli meant something like what I suggested above:
> adding an underline without changing the foreground
> and background colors of the text.  Yes, that could
> be done by face merging (and yes, currently the normal
> fontification gets obliterated).

I think that would be great.  Maybe I misunderstood: I thought Eli was 
suggesting a workaround that worked with Emacs as it is (which would explain 
why Lars closed the bug), but indeed currently using an underline still removes 
other face properties.

Thanks again for your input,
Clément.

signature.asc
Description: OpenPGP digital signature