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

Previous Next

Full log

View this message in rfc822 format

From: Clément Pit-Claudel <clement.pitclaudel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Mon, 4 May 2020 11:16:05 -0400

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.