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

[Drew Adams <drew.adams@oracle.com>]

> 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?

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

Sure, some web pages do different things on a mouseover.
Sometimes they replace (what looks like) the face(s)
used in the link text with a different face or faces.

Sometimes they replace the text itself with different
text, or with the same text in a different font (e.g.
bigger/smaller).

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.

> > 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 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?

My position is that it would be OK to add whatever it
is that you're proposing as an option/alternative, but
not to just replace the current (longstanding) behavior.
My own preference is probably (so far) for a single
face on mouseover, for clarity.

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.

Probably I'd have to play with it, in practice, to
see how much I like it for this or that context.
My point is that whether the value of `mouse-face'
gets merged with `face' values, or it replaces them,
should be under (easy) user and code control.

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

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.

> (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).

Optional is OK by me.  But I'm not sure about the
mechanism.  It should be possible to (optionally)
continue to set property `mouse-face' to a face
and have that face simply used, not merged with
anything.  Having both possibilities is better
than having only one.

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.

One possibility would be to use a different property
from `mouse-face', e.g. `merged-mouse-face' or
whatever.  Another would be, as mentioned, to bind
or set a variable that controls whether the value of
`mouse-face' gets merged.  (The latter gives users
more control than the former.)

> > 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?

Mentioned above.  The visibility of the mouseover
change depends on the value of `mouse-face' differing,
visually, from the `face' (or `font-lock-face' or ...)
property.  When a link is on text with different faces,
parts of it can become less noticeable on mouseover,
depending on text face differences from `mouse-face'.

That's already potentially a problem, but I can imagine
it being manifested more often with face merging.
I think this is the case sometimes for region
highlighting, for example. 

I don't say it's bad - we do that with the region, for
example (well, OK, that's an overlay).  I just say that
I don't think it should systematically _supplant_ the
usual (so far) `mouse-face' behavior.

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