GNU bug report logs - #4911
mouse-face property should merge face attributes, not replace

Previous Next

Package: emacs;

Reported by: Dave Aspinall <daveaspin <at> googlemail.com>

Date: Thu, 12 Nov 2009 12:55:04 UTC

Severity: wishlist

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit-Claudel <clement.pitclaudel <at> gmail.com>
Cc: larsi <at> gnus.org, 4911 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: bug#4911: mouse-face property should merge face attributes, not replace
Date: Fri, 08 May 2020 18:20:20 +0300
> 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.