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

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

[Dave Aspinall]

Dear Emacs developers,

Perhaps this has been noted already: the low-level behaviour of the 
mouse-face property seems ugly: it simply overwrites the face property 
for characters under the mouse.  For example in Info, blue underlined 
links turn black without the underline when the mouse is hovered over 
them to give the green background from the highlight face.  This feels 
unnatural.

In Proof General (http://proofgeneral.inf.ed.ac.uk) we use the 
mouse-face property on programming language text which is heavily 
decorated with font-lock.  Users complain that when the mouse is over a 
region the normal fontification is obliterated.

  - David Aspinall.

PS incidentally, we used to prefer XEmacs for Proof General, its display 
engine did the right thing here.

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

[Lars Ingebrigtsen]

Dave Aspinall <daveaspin@googlemail.com> writes:

> Perhaps this has been noted already: the low-level behaviour of the
> mouse-face property seems ugly: it simply overwrites the face property 
> for characters under the mouse.  For example in Info, blue underlined
> links turn black without the underline when the mouse is hovered over 
> them to give the green background from the highlight face.  This feels
> unnatural.
>
> In Proof General (http://proofgeneral.inf.ed.ac.uk) we use the
> mouse-face property on programming language text which is heavily 
> decorated with font-lock.  Users complain that when the mouse is over
> a region the normal fontification is obliterated.

To reproduce:

(insert (propertize "hello" 'face 'underline 'mouse-face 'highlight))

and put the mouse pointer over the "hello": The underline goes away.

I think it might make sense to merge the properties...  but, on the
other hand, this may make the text illegible.

For instance, this

(insert (propertize "hello" 'face '(:foreground "blue") 'mouse-face 'highlight))

would become a blank, blue box if the highlight face didn't define both a
foreground colour.

So I'm not sure this would work.  Any opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> To reproduce:
>
> (insert (propertize "hello" 'face 'underline 'mouse-face 'highlight))
>
> and put the mouse pointer over the "hello": The underline goes away.

Isn't this long-standing and documented behaviour?  It can be worked
around to an extent by defining mouse-face in terms of face:

  (insert (propertize "hello" 'face 'underline
                      'mouse-face '(:inherit (highlight underline))))

> I think it might make sense to merge the properties...  but, on the
> other hand, this may make the text illegible.

Indeed, I'm not sure this makes sense in the general case, but I'm no
expert.

Thanks,

-- 
Basil

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 01 Oct 2019 16:08:02 +0200
> Cc: 4911@debbugs.gnu.org
> 
> To reproduce:
> 
> (insert (propertize "hello" 'face 'underline 'mouse-face 'highlight))
> 
> and put the mouse pointer over the "hello": The underline goes away.
> 
> I think it might make sense to merge the properties...  but, on the
> other hand, this may make the text illegible.
> 
> For instance, this
> 
> (insert (propertize "hello" 'face '(:foreground "blue") 'mouse-face 'highlight))
> 
> would become a blank, blue box if the highlight face didn't define both a
> foreground colour.
> 
> So I'm not sure this would work.  Any opinions?

Emacs always worked like that: it selects either 'face' or
'mouse-face', according to what is appropriate, and never merges them.

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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> > mouse-face property seems ugly: it simply overwrites the face property
> > for characters under the mouse.  For example in Info, blue underlined
> > links turn black without the underline when the mouse is hovered over
> > them to give the green background from the highlight face.  This feels
> > unnatural.
> >
> > mouse-face property on programming language text which is heavily
> > decorated with font-lock.  Users complain that when the mouse is over
> > a region the normal fontification is obliterated.

FWIW, I don't think it's ugly, and I don't think the
underlying (non mouse-face) face attributes show show
(be merged).

IOW.  I'm one user who prefers the current (longstanding)
behavior.  Just one opinion.

> I think it might make sense to merge the properties...  but, on the
> other hand, this may make the text illegible.

Not just less legible.  Different (conflicting) purposes.

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

Remember too that `mouse-face' can have any face properties
- you are talking about merging arbitrary faces.

Just what is the motivation, besides someone feeling the
behavior is "ugly"?

That font-lock highlighting doesn't show when there's a
link (or some other use of `mouse-face') is a feature,
not a bug.  Why do Proof General users need to see both
kinds of highlighting at the same time?  And merging
could, at least in some cases, make noticing the link etc.
difficult.

To me, it sounds like Proof General should look for
another solution to the problem presented.

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

[Clément Pit-Claudel]

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.

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 3898 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Drew Adams]

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

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 4574 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eli Zaretskii]

> From: Clément Pit-Claudel <clement.pitclaudel@gmail.com>
> Date: Sat, 25 Apr 2020 23:10:42 -0400
> Cc: Lars Ingebrigtsen <larsi@gnus.org>
> 
> > 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.

No, this cannot be done with the current display code, and I'm sorry I
posted a confusing suggestion.

If someone wants to work on an option whereby we will merge the mouse
face with the face of each highlighted character, that would be
welcome.  I just want to warn volunteers that providing such a feature
is not going to be simple: the way mouse-highlight is currently
implemented we simply redraw a stretch of glyphs on the screen with a
face that is already "realized" and cached (see xfaces.c).  Which
means face merging has been already done, and we can only use the
existing faces which were merged long ago.  Making this new feature
happen would then require reimplementing mouse-highlight similar to
the region (some kind of overlay), and I hope the result will not
cause annoying flicker, since in principle we will have to trigger
redisplay on each mouse move, unlike a much simpler redraw we do now.

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

[Drew Adams]

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

I don't think I see that on nytimes.com or google.com.

I do see a mouseover "face" change on both, on inline
links in text, but what I see is all or nothing.  For
NYT, for example, a link is shown underlined, and
mouseover removes the underline - IOW, two different
"faces", and mouseover uses the same face for all of
the link text.

I don't see examples of link text that has (the
equivalent of) multiple faces, so I can't see what
happens with mouseover on such links.

Do you have an example of a link on some such site,
where the link text uses multiple "faces" and
mouseover preserves those faces while perhaps adding
or removing some "face attributes" across all of them?

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

I thought so.  But probably "more or less", and not
violently. ;-)

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

I think it can depend on the background, and how it
interacts with the default/frame face and with the
faces used in the link text.  You may be right that
in general most mouseover backgrounds would not be
problematic; 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.
> 
> 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.

The question is really about links (mouseover).

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

It would be good to try a patch, in some context where
there is already lots of use of different faces.  One
such context is the use of font-lock faces, but in most
such uses there isn't much predefined use of links.

> Thanks again for your input,

And thank you for the suggestion/bug report, and
attention to providing the new feature only as an
option/alternative.

(BTW, why doesn't the bug # appear in the subject line?)

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1269 bytes --]

On 26/04/2020 09.34, Eli Zaretskii wrote:
> If someone wants to work on an option whereby we will merge the mouse
> face with the face of each highlighted character, that would be 
> welcome.  I just want to warn volunteers that providing such a 
> feature is not going to be simple: the way mouse-highlight is 
> currently implemented we simply redraw a stretch of glyphs on the 
> screen with a face that is already "realized" and cached (see 
> xfaces.c).  Which means face merging has been already done, and we 
> can only use the existing faces which were merged long ago.  Making 
> this new feature happen would then require reimplementing 
> mouse-highlight similar to the region (some kind of overlay)

Thanks a lot, this summary was very useful.
I've been pondering this issue since your last message, hoping to find a way to keep the complexity down and not introduce flickering.

Currently we cache a single realized mouse_face.  Could we cache a sequence of such realized faces instead, attached to regions of text?  That is, we'd compute the realized mouse-face for all regions of the current span, and cache that.  Concretely, I guess this would mean enhancing Mouse_HLInfo to keep a list of spans instead of a single one.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eli Zaretskii]

> Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org
> From: Clément Pit-Claudel <clement.pitclaudel@gmail.com>
> Date: Mon, 4 May 2020 11:16:05 -0400
> 
> Currently we cache a single realized mouse_face.  Could we cache a sequence of such realized faces instead, attached to regions of text?  That is, we'd compute the realized mouse-face for all regions of the current span, and cache that.  Concretely, I guess this would mean enhancing Mouse_HLInfo to keep a list of spans instead of a single one.

I'm not sure I understand what you mean by "span" in general and
"current span" in particular.

We could, of course, realize such combinations.  It would need:

  . realizing and caching 2 faces whenever we render some text which
    has a mouse-face property;
  . recording the buffer positions to which those realized mouse-faces
    are relevant; and
  . using the corresponding face when redrawing the highlighted
    portions of text by looking at the positions of each of the
    affected glyphs (which might be complicated if the text doesn't
    come from a buffer)

    

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1490 bytes --]

On 08/05/2020 10.39, Eli Zaretskii wrote:
>> Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org
>> From: Clément Pit-Claudel <clement.pitclaudel@gmail.com>
>> Date: Mon, 4 May 2020 11:16:05 -0400
>>
>> Currently we cache a single realized mouse_face.  Could we cache a sequence of such realized faces instead, attached to regions of text?  That is, we'd compute the realized mouse-face for all regions of the current span, and cache that.  Concretely, I guess this would mean enhancing Mouse_HLInfo to keep a list of spans instead of a single one.
> 
> I'm not sure I understand what you mean by "span" in general and
> "current span" in particular.

I meant a range of text with a single mouse-face property.

> We could, of course, realize such combinations.  It would need:
> 
>   . realizing and caching 2 faces whenever we render some text which
>     has a mouse-face property;

Don't we already do this, currently?

>   . recording the buffer positions to which those realized mouse-faces
>     are relevant; and

That makes sense.  Basically, I was hoping to change Mouse_HLInfo to contain more than one range and more than one face.

>   . using the corresponding face when redrawing the highlighted
>     portions of text by looking at the positions of each of the
>     affected glyphs (which might be complicated if the text doesn't
>     come from a buffer)

But isn't that already taken care of by the existing highlighting code?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eli Zaretskii]

> Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org
> From: Clément Pit-Claudel <clement.pitclaudel@gmail.com>
> Date: Fri, 8 May 2020 11:01:35 -0400
> 
> > I'm not sure I understand what you mean by "span" in general and
> > "current span" in particular.
> 
> I meant a range of text with a single mouse-face property.

But if the underlying text has different face properties, the range of
text should now be divided into different "spans", no?

> >   . realizing and caching 2 faces whenever we render some text which
> >     has a mouse-face property;
> 
> Don't we already do this, currently?

No, because we only have a single mouse-face.  With this feature, we'd
have multiple ones, and they are only known when the face of the text
is being realized, because each character could have different sources
of face information, which need to be merged.

> >   . recording the buffer positions to which those realized mouse-faces
> >     are relevant; and
> 
> That makes sense.  Basically, I was hoping to change Mouse_HLInfo to contain more than one range and more than one face.

Maybe that, too, will have to be used.

> >   . using the corresponding face when redrawing the highlighted
> >     portions of text by looking at the positions of each of the
> >     affected glyphs (which might be complicated if the text doesn't
> >     come from a buffer)
> 
> But isn't that already taken care of by the existing highlighting code?

No, because the existing code always uses the same mouse-face.  So it
only needs to know which glyphs need to be redrawn with that single
face.

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1854 bytes --]

On 08/05/2020 11.20, Eli Zaretskii wrote:
>> Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org
>> From: Clément Pit-Claudel <clement.pitclaudel@gmail.com>
>> Date: Fri, 8 May 2020 11:01:35 -0400
>>
>>> I'm not sure I understand what you mean by "span" in general and
>>> "current span" in particular.
>>
>> I meant a range of text with a single mouse-face property.
> 
> But if the underlying text has different face properties, the range of
> text should now be divided into different "spans", no?

Yes, sorry for the confusing terminology :'(
Basically I meant to say that we keep the code used for locating which span of text is covered by a mouse highlight; namely, we look for a range of text with an `eq' mouse-face value.

>>>   . realizing and caching 2 faces whenever we render some text which
>>>     has a mouse-face property;
>>
>> Don't we already do this, currently?
> 
> No, because we only have a single mouse-face.  With this feature, we'd
> have multiple ones, and they are only known when the face of the text
> is being realized, because each character could have different sources
> of face information, which need to be merged.

Ah, I see.  Right now we don't need to look at the regular faces at all; of course.

>>>   . using the corresponding face when redrawing the highlighted
>>>     portions of text by looking at the positions of each of the
>>>     affected glyphs (which might be complicated if the text doesn't
>>>     come from a buffer)
>>
>> But isn't that already taken care of by the existing highlighting code?
> 
> No, because the existing code always uses the same mouse-face.  So it
> only needs to know which glyphs need to be redrawn with that single
> face.

Got it.  My hope was that changing Mouse_HLInfo would allow us to get this almost "for free"


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]