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

[Clément Pit-Claudel]

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:
> Why would one suppose that someone wants to merge that face with 
> `mouse-face'?

There's no need to suppose: users complained.
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.

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

I think it would help to understand what the motivation is for erasing existing 
faces when applying the mouse face.  Drew, what does this behavior improve for 
you?
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?
(Besides, as I wrote in my previous email, merging faces would be optional, 
since it would be easy to set a mouse-face to inherit from 'default and 
therefore completely remove existing highlighting).

> And merging could, at least in some cases, make noticing the link 
> etc. difficult.

I didn't understand this part.  In which cases would merging the mouse face 
with the underlying face *when the mouse is over the link* make noticing the 
link harder?  When the mouse is over the link, the cursor typically changes 
shape; and, while the mouse was not over the link, it typically had separate 
highlighting.  Why would merging faces when the mouse is over the link make the 
link harder to notice?

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.

Cheers,
Clément.

On 10/04/2020 12.26, Clément Pit-Claudel wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> I see no reason to change that now.  The use case described in the bug
>>> report could be handled by using some non-color attribute for the
>>> mouse-face, for example.
>>
>> Seems like everybody agrees, so I'm closing this bug report.
> 
> I'd like to disagree :) This is a problem I've run into in various packages 
> and as a user, and the workaround doesn't work when there are multiple 
> different faces applied to the text of a link.
> 
> As a concrete example, consider compilation-mode, which uses different colors 
> for the file name, the line number, the column number, and the error message. 
>  Currently, when hovering over a compilation-mode line highlights it, but 
> also causes it to lose all of its other highlighting.
> 
> Setting different mouse-face properties to match the different faces would 
> cause the mouse-face highlighting to be only applied to part of the line.
> 
> Of course, one way to go is to handle mouse-in and mouse-out events in Lisp, 
> creating and removing overlays as needed.  But that's explicitly recommended 
> against in the ELisp manual, and it's a lot of work for not much gain.
> 
> It would be great to have an option for this; maybe as an extra text 
> property, like 'mouse-face-merge?  Or maybe as a user option?
> Of course, if the default changed to merging, recovering the current behavior 
> would be easy even without an extra property (it would just be a matter of 
> making the mouse-face inherit from 'default), I think.  But even without 
> changing the default it would be nice to introduce a way to achieve that 
> behavior.
> 
> Clément.
>

signature.asc
Description: OpenPGP digital signature