[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#4911: mouse-face property should merge face attributes, not replace
From: |
Clément Pit-Claudel |
Subject: |
bug#4911: mouse-face property should merge face attributes, not replace |
Date: |
Fri, 8 May 2020 11:01:35 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 08/05/2020 10.39, Eli Zaretskii wrote:
>> Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org
>> From: Clément Pit-Claudel <clement.pitclaudel@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.
I meant a range of text with a single mouse-face property.
> 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;
Don't we already do this, currently?
> . 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.
> . 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?
signature.asc
Description: OpenPGP digital signature