[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67794: 30.0.50; mouse-face is not respected on SVG images
From: |
Eli Zaretskii |
Subject: |
bug#67794: 30.0.50; mouse-face is not respected on SVG images |
Date: |
Tue, 12 Dec 2023 16:47:13 +0200 |
> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Alan Third <alan@idiocy.org>, 67794@debbugs.gnu.org
> Date: Tue, 12 Dec 2023 15:07:13 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Basically, SVG images specify their own background color, and the
> > Emacs display cannot override that, since the image is generated by
> > librsvg. So to change the background color, we wrap the SVG in
> > another SVG, see svg_load_image. This way, the SVG spec submitted to
> > librsvg specifies different colors according to what Emacs wants. And
> > we only do that for colors that come from 'face' properties.
>
> This means that when you do a 'C-s foobar' and that the SVG is correctly
> displayed with the isearch face (foreground and background), such an
> embedded SVG was created on the fly? If so, I think we should do the
> same for mouse-face too because this SVG generation is very fast!
Not sure "fast" is fast enough, since unlike face properties,
mouse-highlight is highly dynamic, and creating a new image each time
(as I think this would mean) is something we want. Let's wait for
Alan to chime in with his insights.
> >> (note: I have tried to track this down but debugging Emacs display is
> >> *hard*. I have read and tried the "Debugging Emacs redisplay problems"
> >> section of etc/DEBUG with no luck so far.)
> >
> > The mouse highlight is implemented in note_mouse_highlight and its
> > subroutines. If you already discovered that, then what were the
> > difficulties you faced in understanding what happens?
>
> Yes, I used to put a break point on show_mouse_face but then diving down
> to x_draw_glyph_string it is hard to "see" what is going on here.
We are drawing a series of glyphs of the same type which share the
same face/mouse-face. For SVG, it would probably mean we are drawing
that single SVG (which is a single glyph), since series of images are
usually rare.
> As it was working with face such as isearch, my new strategy was to
> find out how it worked here but now I don't know where/how to break
> to the correct place.
show_mouse_face calls draw_row_with_mouse_face, which calls
draw_glyphs, which builds a "glyph string" and then calls the frame's
draw_glyph_string method, which on X is x_draw_glyph_string. The
latter eventually calls x_draw_image_glyph_string. HTH.
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, (continued)
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Manuel Giraud, 2023/12/19
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Eli Zaretskii, 2023/12/19
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Manuel Giraud, 2023/12/19
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Eli Zaretskii, 2023/12/19
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Manuel Giraud, 2023/12/20
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Eli Zaretskii, 2023/12/20
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Alan Third, 2023/12/20
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Manuel Giraud, 2023/12/20
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Manuel Giraud, 2023/12/20
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Eli Zaretskii, 2023/12/23
- bug#67794: 30.0.50; mouse-face is not respected on SVG images,
Eli Zaretskii <=
- bug#67794: 30.0.50; mouse-face is not respected on SVG images, Alan Third, 2023/12/12