GNU bug report logs -
#4911
mouse-face property should merge face attributes, not replace
Previous Next
Full log
View this message in rfc822 format
> Cc: drew.adams <at> oracle.com, 4911 <at> debbugs.gnu.org, larsi <at> gnus.org
> From: Clément Pit-Claudel <clement.pitclaudel <at> 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.
This bug report was last modified 5 years and 14 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.