From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#67794: 30.0.50; mouse-face is not respected on SVG images Date: Tue, 12 Dec 2023 14:43:08 +0000 Message-ID: References: <87plzb7eek.fsf@ledu-giraud.fr> <83sf47tumh.fsf@gnu.org> <87jzpjo6pa.fsf@ledu-giraud.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30301"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67794@debbugs.gnu.org, Eli Zaretskii To: Manuel Giraud Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 12 15:44:09 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rD3zU-0007dX-Ip for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Dec 2023 15:44:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rD3zA-0006fr-MQ; Tue, 12 Dec 2023 09:43:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rD3z9-0006f1-D5 for bug-gnu-emacs@gnu.org; Tue, 12 Dec 2023 09:43:47 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rD3z9-0001ly-5R for bug-gnu-emacs@gnu.org; Tue, 12 Dec 2023 09:43:47 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rD3zO-0006eE-Ac for bug-gnu-emacs@gnu.org; Tue, 12 Dec 2023 09:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Dec 2023 14:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67794 X-GNU-PR-Package: emacs Original-Received: via spool by 67794-submit@debbugs.gnu.org id=B67794.170239221425511 (code B ref 67794); Tue, 12 Dec 2023 14:44:02 +0000 Original-Received: (at 67794) by debbugs.gnu.org; 12 Dec 2023 14:43:34 +0000 Original-Received: from localhost ([127.0.0.1]:55606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rD3yv-0006dP-Oz for submit@debbugs.gnu.org; Tue, 12 Dec 2023 09:43:34 -0500 Original-Received: from dane.soverin.net ([2a10:de80:1:4092:b9e9:229d:0:1]:48115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rD3ys-0006d9-O7 for 67794@debbugs.gnu.org; Tue, 12 Dec 2023 09:43:32 -0500 Original-Received: from smtp.soverin.net (unknown [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4SqLvJ6FPdz101P; Tue, 12 Dec 2023 14:43:08 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4SqLvJ3ycWzC1; Tue, 12 Dec 2023 14:43:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1702392188; bh=AfHe8ID5mmAcvksG+KXqPQWYg4fxozqBqEtge2wCcMw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=D6GL1hPawWCfvGETt7f7i19v4lH/1nOS9ou8RsoFVUewihyGU0Fuq9+kYOYfRjwUH ITNnxiapISCYPFWs70GUKWBSo4JndCnbYsGiIb33H1xBQqiwIIZJaH9ZZBATHJoVZo DZSLSMWNREtXzvLI6cGZMaySxxAtcBzVyTJT4QOXbk9pGsA8fvQ1eNu2PTV7zAaqV2 3rC8z69Bxtn4l2M3kE7fRcYqaU1pbbBTvI8Ee7g3yKWD6QYluQFbqet5O8DQ8nu+5I Ldz0dcOB2jWRxt9vpF8fYxGuh3CFIj0dyl4UnItYCQ/VXPsT4iY9m8bSWVX+h5FfQa FcSw5CC5h67Tg== Original-Received: from alan by faroe.holly.idiocy.org with local (Exim 4.96) (envelope-from ) id 1rD3yW-0007x8-0D; Tue, 12 Dec 2023 14:43:08 +0000 Mail-Followup-To: Alan Third , Manuel Giraud , Eli Zaretskii , 67794@debbugs.gnu.org Content-Disposition: inline In-Reply-To: <87jzpjo6pa.fsf@ledu-giraud.fr> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:276047 Archived-At: On Tue, Dec 12, 2023 at 03:07:13PM +0100, Manuel Giraud wrote: > Eli Zaretskii writes: > > [...] > > >> Now a 'C-s foobar' shows the matched string respecting the isearch face > >> even on the SVG image. But when, you move your mouse over the "foobar" > >> string, the SVG image keeps the foreground and background of the default > >> face. > > > > I think we only support colors from 'face' properties on SVG images, > > not from 'mouse-face'. Alan, am I right? Yes, that's right. > > 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! I don't see any reason why we shouldn't do that. lookup_image in image.c is where most of the work is done. It takes a face ID number. There are three calls to it from xdisp.c. I don't know if it would be best to change the callers to pass in the mouse face instead of the local face, or to pass in the mouse face as well as the local face and then allow lookup_image to work it out. This assumes the mouse face details have been worked out before the calls to lookup_image, I don't know much about how it works. -- Alan Third