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


Message #52 received at 4911 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#4911: mouse-face property should merge face attributes, not
 replace
Date: Fri, 08 May 2020 17:39:22 +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: 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)

    




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.