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