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.