GNU bug report logs - #77429
31.0.50; Image map and display slice on mode/header/tab line

Previous Next

To reply to this bug, email your comments to 77429 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: David Ponce <da_vid <at> orange.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Image map and display slice on mode/header/tab line
Date: Tue, 1 Apr 2025 15:06:49 +0200

Hello,

I discovered an inconsistency in the interpretation of image map
coordinates when the sliced image is displayed, depending on whether it's
displayed in a buffer or in a mode, header or tab line.

When the sliced image is displayed in a buffer, the image coordinates
remain relative to the unclipped image, which looks correct to me.  But,
it is no longer the case when the image is displayed in a mode, header
or tab line: then the image map coordinates become relative to the
visible portion of the image, which renders the map unusable.  The
following code illustrates the problem:

(require 'svg)
(let* ((w 304)
       (h (frame-char-height))
       (svg (svg-create w h)))
  (svg-rectangle svg 0   0 100 h :fill "red")
  (svg-rectangle svg 102 0 100 h :fill "green")
  (svg-rectangle svg 204 0 100 h :fill "blue")
  (let* ((img (svg-image svg :scale 1
                         :map
                         `(
                           ((rect . ((0   . 0) . (100 . ,h)))
                            r (help-echo "RED"   pointer hand))
                           ((rect . ((102 . 0) . (202 . ,h)))
                            g (help-echo "GREEN" pointer hand))
                           ((rect . ((204 . 0) . (304 . ,h)))
                            b (help-echo "BLUE"  pointer hand))
                           )))
         (full (propertize " " 'display img))
         (cut  (propertize " " 'display `((slice 102 0 202 1.0) ,img)))
         (both (concat cut " " full)))
    (setq header-line-format both)
    (insert both "\n")))

I'm reporting this inconsistency, at least to find out if it's a real
bug or a limitation that needs to be addressed by the programmer.

Thanks


In GNU Emacs 31.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.0) of 2025-03-31
Repository revision: 6f311883d246df87fa3ed9c24dbb39078e3fd69f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 40 (KDE Plasma)

Configured using:
 'configure --with-native-compilation=no'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

Important settings:
  value of $LC_TIME: fr_FR.utf8
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 77429 <at> debbugs.gnu.org
Subject: Re: bug#77429: 31.0.50;
 Image map and display slice on mode/header/tab line
Date: Tue, 01 Apr 2025 18:43:08 +0300

> Date: Tue, 1 Apr 2025 15:06:49 +0200
> From:  David Ponce via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> (require 'svg)
> (let* ((w 304)
>         (h (frame-char-height))
>         (svg (svg-create w h)))
>    (svg-rectangle svg 0   0 100 h :fill "red")
>    (svg-rectangle svg 102 0 100 h :fill "green")
>    (svg-rectangle svg 204 0 100 h :fill "blue")
>    (let* ((img (svg-image svg :scale 1
>                           :map
>                           `(
>                             ((rect . ((0   . 0) . (100 . ,h)))
>                              r (help-echo "RED"   pointer hand))
>                             ((rect . ((102 . 0) . (202 . ,h)))
>                              g (help-echo "GREEN" pointer hand))
>                             ((rect . ((204 . 0) . (304 . ,h)))
>                              b (help-echo "BLUE"  pointer hand))
>                             )))
>           (full (propertize " " 'display img))
>           (cut  (propertize " " 'display `((slice 102 0 202 1.0) ,img)))
>           (both (concat cut " " full)))
>      (setq header-line-format both)
>      (insert both "\n")))
> 
> I'm reporting this inconsistency, at least to find out if it's a real
> bug or a limitation that needs to be addressed by the programmer.

Bug.  And a very old one.  Should be fixed now on the master branch;
please test.

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

From: David Ponce <da_vid <at> orange.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77429 <at> debbugs.gnu.org
Subject: Re: bug#77429: 31.0.50; Image map and display slice on
 mode/header/tab line
Date: Tue, 1 Apr 2025 19:57:14 +0200

On 2025-04-01 17:43, Eli Zaretskii wrote:
>> Date: Tue, 1 Apr 2025 15:06:49 +0200
>> From:  David Ponce via "Bug reports for GNU Emacs,
>>   the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> (require 'svg)
>> (let* ((w 304)
>>          (h (frame-char-height))
>>          (svg (svg-create w h)))
>>     (svg-rectangle svg 0   0 100 h :fill "red")
>>     (svg-rectangle svg 102 0 100 h :fill "green")
>>     (svg-rectangle svg 204 0 100 h :fill "blue")
>>     (let* ((img (svg-image svg :scale 1
>>                            :map
>>                            `(
>>                              ((rect . ((0   . 0) . (100 . ,h)))
>>                               r (help-echo "RED"   pointer hand))
>>                              ((rect . ((102 . 0) . (202 . ,h)))
>>                               g (help-echo "GREEN" pointer hand))
>>                              ((rect . ((204 . 0) . (304 . ,h)))
>>                               b (help-echo "BLUE"  pointer hand))
>>                              )))
>>            (full (propertize " " 'display img))
>>            (cut  (propertize " " 'display `((slice 102 0 202 1.0) ,img)))
>>            (both (concat cut " " full)))
>>       (setq header-line-format both)
>>       (insert both "\n")))
>>
>> I'm reporting this inconsistency, at least to find out if it's a real
>> bug or a limitation that needs to be addressed by the programmer.
> 
> Bug.  And a very old one.  Should be fixed now on the master branch;
> please test.

It seems the bug is only partially fixed.  The image map behaves as
expected for the help-echo and pointer properties, but doesn't report
the correct hot spot ID.  The updated recipe below illustrates this:

(require 'svg)
(let* ((w 304)
       (h (frame-char-height))
       (svg (svg-create w h))
       (km (define-keymap
             "<r> <mouse-1>"
             (lambda () (interactive) (message "Red"))
             "<g> <mouse-1>"
             (lambda () (interactive) (message "Green"))
             "<b> <mouse-1>"
             (lambda () (interactive) (message "Blue")))))
  (svg-rectangle svg 0   0 100 h :fill "red")
  (svg-rectangle svg 102 0 100 h :fill "green")
  (svg-rectangle svg 204 0 100 h :fill "blue")
  (let* ((img (svg-image svg :scale 1
                         :map
                         `(
                           ((rect . ((0   . 0) . (100 . ,h)))
                            r (help-echo "RED"   pointer hand))
                           ((rect . ((102 . 0) . (202 . ,h)))
                            g (help-echo "GREEN" pointer hand))
                           ((rect . ((204 . 0) . (304 . ,h)))
                            b (help-echo "BLUE"  pointer hand))
                           )))
         (full (propertize " " 'display img
                           'keymap km))
         (cut  (propertize " " 'display `((slice 102 0 202 1.0) ,img)
                           'keymap km))
         (both (concat cut " " full)))
    (setq header-line-format both)
    (insert both "\n")))

Thanks!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 77429 <at> debbugs.gnu.org
Subject: Re: bug#77429: 31.0.50; Image map and display slice on
 mode/header/tab line
Date: Tue, 01 Apr 2025 21:53:03 +0300

> Date: Tue, 1 Apr 2025 19:57:14 +0200
> Cc: 77429 <at> debbugs.gnu.org
> From: David Ponce <da_vid <at> orange.fr>
> 
> It seems the bug is only partially fixed.  The image map behaves as
> expected for the help-echo and pointer properties, but doesn't report
> the correct hot spot ID.  The updated recipe below illustrates this:

Sorry, I don't understand what that means.

Would you please accompany the code with some minimal description of
how to produce the wrong result (and explanation why you think it's
wrong)?  The previous example was already somewhat of a riddle, but at
least with the wrong help-echo shown it was relatively easy to guess
what was expected.  This time I'm completely stomped: what is "hot
spot ID" and how do I see it?

Thanks.

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

From: David Ponce <da_vid <at> orange.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77429 <at> debbugs.gnu.org
Subject: Re: bug#77429: 31.0.50; Image map and display slice on
 mode/header/tab line
Date: Tue, 1 Apr 2025 21:31:39 +0200

On 2025-04-01 20:53, Eli Zaretskii wrote:
>> Date: Tue, 1 Apr 2025 19:57:14 +0200
>> Cc: 77429 <at> debbugs.gnu.org
>> From: David Ponce <da_vid <at> orange.fr>
>>
>> It seems the bug is only partially fixed.  The image map behaves as
>> expected for the help-echo and pointer properties, but doesn't report
>> the correct hot spot ID.  The updated recipe below illustrates this:
> 
> Sorry, I don't understand what that means.
> 
> Would you please accompany the code with some minimal description of
> how to produce the wrong result (and explanation why you think it's
> wrong)?  The previous example was already somewhat of a riddle, but at
> least with the wrong help-echo shown it was relatively easy to guess
> what was expected.  This time I'm completely stomped: what is "hot
> spot ID" and how do I see it?
> 
> Thanks.

Sorry for not being precise enough.

The hot spot ID is documented in the Elisp manual:

‘:map MAP’
     This associates an image map of “hot spots” with this image.

     An image map is an alist where each element has the format ‘(AREA
     ID PLIST)’.  An AREA is specified as either a rectangle, a circle,
     or a polygon.

     [...]
 
     When you click the mouse when the mouse pointer is over a hot-spot,
     an event is composed by combining the ID of the hot-spot with the
     mouse event; for instance, ‘[area4 mouse-1]’ if the hot-spot's ID
     is ‘area4’.

In my example, each colored rectangle RED, GREEN, BLUE corresponds to
a `rect' hot spot with the respective IDs: r, g, b.  And Each <ID
mouse-1> key is associated to a command that displays the color name
of the rectangle you click on.

So, when you click on the red rectangle you should see "Red" is the
echo area, "Green" when you click on the green rectangle, and "Blue"
when you click on the blue rectangle.

But on the sliced image which is on the left side on the header line,
showing a green and blue rectangle, a click on the green rectangle
displays "Red" instead of "Green" and click on the blue rectangle
displays "Green" instead of "Blue".  This is the issue.

Hope I am clear enough.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 77429 <at> debbugs.gnu.org
Subject: Re: bug#77429: 31.0.50; Image map and display slice on
 mode/header/tab line
Date: Wed, 02 Apr 2025 16:13:43 +0300

> Date: Tue, 1 Apr 2025 21:31:39 +0200
> Cc: 77429 <at> debbugs.gnu.org
> From: David Ponce <da_vid <at> orange.fr>
> 
> On 2025-04-01 20:53, Eli Zaretskii wrote:
> >> Date: Tue, 1 Apr 2025 19:57:14 +0200
> >> Cc: 77429 <at> debbugs.gnu.org
> >> From: David Ponce <da_vid <at> orange.fr>
> >>
> >> It seems the bug is only partially fixed.  The image map behaves as
> >> expected for the help-echo and pointer properties, but doesn't report
> >> the correct hot spot ID.  The updated recipe below illustrates this:
> > 
> > Sorry, I don't understand what that means.
> > 
> > Would you please accompany the code with some minimal description of
> > how to produce the wrong result (and explanation why you think it's
> > wrong)?  The previous example was already somewhat of a riddle, but at
> > least with the wrong help-echo shown it was relatively easy to guess
> > what was expected.  This time I'm completely stomped: what is "hot
> > spot ID" and how do I see it?
> > 
> > Thanks.
> 
> Sorry for not being precise enough.
> 
> The hot spot ID is documented in the Elisp manual:
> 
> ‘:map MAP’
>       This associates an image map of “hot spots” with this image.
> 
>       An image map is an alist where each element has the format ‘(AREA
>       ID PLIST)’.  An AREA is specified as either a rectangle, a circle,
>       or a polygon.
> 
>       [...]
>   
>       When you click the mouse when the mouse pointer is over a hot-spot,
>       an event is composed by combining the ID of the hot-spot with the
>       mouse event; for instance, ‘[area4 mouse-1]’ if the hot-spot's ID
>       is ‘area4’.
> 
> In my example, each colored rectangle RED, GREEN, BLUE corresponds to
> a `rect' hot spot with the respective IDs: r, g, b.  And Each <ID
> mouse-1> key is associated to a command that displays the color name
> of the rectangle you click on.
> 
> So, when you click on the red rectangle you should see "Red" is the
> echo area, "Green" when you click on the green rectangle, and "Blue"
> when you click on the blue rectangle.
> 
> But on the sliced image which is on the left side on the header line,
> showing a green and blue rectangle, a click on the green rectangle
> displays "Red" instead of "Green" and click on the blue rectangle
> displays "Green" instead of "Blue".  This is the issue.
> 
> Hope I am clear enough.

Yes, thanks.  Should be fixed now on the master branch.

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

From: David Ponce <da_vid <at> orange.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77429 <at> debbugs.gnu.org
Subject: Re: bug#77429: 31.0.50; Image map and display slice on
 mode/header/tab line
Date: Wed, 2 Apr 2025 15:50:01 +0200

On 2025-04-02 15:13, Eli Zaretskii wrote:
>> Date: Tue, 1 Apr 2025 21:31:39 +0200
>> Cc: 77429 <at> debbugs.gnu.org
>> From: David Ponce <da_vid <at> orange.fr>
>>
>> On 2025-04-01 20:53, Eli Zaretskii wrote:
>>>> Date: Tue, 1 Apr 2025 19:57:14 +0200
>>>> Cc: 77429 <at> debbugs.gnu.org
>>>> From: David Ponce <da_vid <at> orange.fr>
>>>>
>>>> It seems the bug is only partially fixed.  The image map behaves as
>>>> expected for the help-echo and pointer properties, but doesn't report
>>>> the correct hot spot ID.  The updated recipe below illustrates this:
>>>
>>> Sorry, I don't understand what that means.
>>>
>>> Would you please accompany the code with some minimal description of
>>> how to produce the wrong result (and explanation why you think it's
>>> wrong)?  The previous example was already somewhat of a riddle, but at
>>> least with the wrong help-echo shown it was relatively easy to guess
>>> what was expected.  This time I'm completely stomped: what is "hot
>>> spot ID" and how do I see it?
>>>
>>> Thanks.
>>
>> Sorry for not being precise enough.
>>
>> The hot spot ID is documented in the Elisp manual:
>>
>> ‘:map MAP’
>>        This associates an image map of “hot spots” with this image.
>>
>>        An image map is an alist where each element has the format ‘(AREA
>>        ID PLIST)’.  An AREA is specified as either a rectangle, a circle,
>>        or a polygon.
>>
>>        [...]
>>    
>>        When you click the mouse when the mouse pointer is over a hot-spot,
>>        an event is composed by combining the ID of the hot-spot with the
>>        mouse event; for instance, ‘[area4 mouse-1]’ if the hot-spot's ID
>>        is ‘area4’.
>>
>> In my example, each colored rectangle RED, GREEN, BLUE corresponds to
>> a `rect' hot spot with the respective IDs: r, g, b.  And Each <ID
>> mouse-1> key is associated to a command that displays the color name
>> of the rectangle you click on.
>>
>> So, when you click on the red rectangle you should see "Red" is the
>> echo area, "Green" when you click on the green rectangle, and "Blue"
>> when you click on the blue rectangle.
>>
>> But on the sliced image which is on the left side on the header line,
>> showing a green and blue rectangle, a click on the green rectangle
>> displays "Red" instead of "Green" and click on the blue rectangle
>> displays "Green" instead of "Blue".  This is the issue.
>>
>> Hope I am clear enough.
> 
> Yes, thanks.  Should be fixed now on the master branch.

Yes, I confirm the bug is now fixed.
From my side, you can close this report.
Thank you very much!

Message #28 received at 77429-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 77429-done <at> debbugs.gnu.org
Subject: Re: bug#77429: 31.0.50; Image map and display slice on
 mode/header/tab line
Date: Wed, 02 Apr 2025 17:01:54 +0300

> Date: Wed, 2 Apr 2025 15:50:01 +0200
> Cc: 77429 <at> debbugs.gnu.org
> From: David Ponce <da_vid <at> orange.fr>
> 
> >> But on the sliced image which is on the left side on the header line,
> >> showing a green and blue rectangle, a click on the green rectangle
> >> displays "Red" instead of "Green" and click on the blue rectangle
> >> displays "Green" instead of "Blue".  This is the issue.
> >>
> >> Hope I am clear enough.
> > 
> > Yes, thanks.  Should be fixed now on the master branch.
> 
> Yes, I confirm the bug is now fixed.
>  From my side, you can close this report.

Done.

Previous Next

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