GNU bug report logs - #71162
27.1; toolbar icons

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71162 in the body.
You can then email your comments to 71162 AT debbugs.gnu.org in the normal way.

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

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

From: David McCracken <davidm <at> ixont.com>
To: bug-gnu-emacs <at> gnu.org
Subject: bug-gnu-emacs <at> gnu.org
Date: Thu, 23 May 2024 21:08:24 -0700

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

From: d <d <at> X990.i-did-not-set--mail-host-address--so-tickle-me>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; toolbar icons
My Linux computers are used only for local development and don't have 
email access. I copied this from the Linux computer (X990) in which the 
problem exists. That I am sending this to you from a Windows computer is 
irrelevant.
--text follows this line--
I have developed a library that includes a toolbar with custom icons. It
works in all versions of Emacs in Windows and in Emacs version 26.3
under Ubuntu-Mate 20.54 but the toolbar doesn't work in Emacs 27.1 under
Ubuntu-Mate 22.04. In my preferred configuration I put my icons under
the user home directory so that this doesn't change if Emacs is
updated. My library accesses this with e.g.
(tool-bar-add-item "~/icons/lxa-next"
to use my lxa-next.xpm icon. In Emacs 26.3 it also works to put my icon
in /usr/share/emacs/26.3/etc/images and refer to it as simply
"lxa-next". Emacs 27.1 shows nothing either way. My lxa-next.xpm appears
similar to the native lock-broken.xpm (4.7kB vs. 4.6kB) so I
experimented referring to that instead of mine and it worked. I also
tested left-arrow but instead of left-arrow.xpm or pbm, it showed a very
plain < image that doesn't exist in the images directory. It should be
noted that there is a lock-broken.pbm but the xpm version was
automatically selected. The icon selection mechanism of Emacs 26.3 is
usable but could be improved by accepting an explicit icon file
extension. That of 27.1 is unusable and, unless we can fix it, I will
have to advise users of my library to install an older version of Emacs.

In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0)
 of 2023-08-16, modified by Debian built on lcy02-amd64-041
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.4 LTS

Recent messages:
Invalid XPM3 file ((image :type xpm :file 
/usr/share/emacs/27.1/etc/images/lxa-next.xpm))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-fwdlink.xpm))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-pin.xpm))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-prev.xpm))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-next.xpm))
Invalid XPM3 file ((image :type xpm :file 
/usr/share/emacs/27.1/etc/images/lxa-next.xpm :mask heuristic))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-fwdlink.xpm 
:mask heuristic))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-pin.xpm 
:mask heuristic))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-prev.xpm 
:mask heuristic))
Invalid XPM3 file ((image :type xpm :file /home/d/icons/lxa-next.xpm 
:mask heuristic))

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --enable-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-cairo
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2
 -ffile-prefix-map=/build/emacs-WL9mhG/emacs-27.1+1=. 
-fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

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

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

Major mode: Emacs-Lisp

Minor modes in effect:
  show-paren-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date server
cus-edit cus-start cus-load wid-edit linkxall edmacro kmacro pcase paren
delsel bs finder-inf package easymenu browse-url url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 91987 8892)
  (symbols 48 9691 1)
  (strings 32 26045 2661)
  (string-bytes 1 804745)
  (vectors 16 14071)
  (vector-slots 8 176572 9434)
  (floats 8 34 18)
  (intervals 56 1929 0)
  (buffers 1000 12))

[lxa-next.xpm (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David McCracken <davidm <at> ixont.com>
Cc: 71162 <at> debbugs.gnu.org
Subject: Re: bug#71162: bug-gnu-emacs <at> gnu.org
Date: Fri, 24 May 2024 09:15:54 +0300

> Date: Thu, 23 May 2024 21:08:24 -0700
> From: David McCracken <davidm <at> ixont.com>
> 
> I have developed a library that includes a toolbar with custom icons. It
> works in all versions of Emacs in Windows and in Emacs version 26.3
> under Ubuntu-Mate 20.54 but the toolbar doesn't work in Emacs 27.1 under
> Ubuntu-Mate 22.04. In my preferred configuration I put my icons under
> the user home directory so that this doesn't change if Emacs is
> updated. My library accesses this with e.g.
> (tool-bar-add-item "~/icons/lxa-next"
> to use my lxa-next.xpm icon. In Emacs 26.3 it also works to put my icon
> in /usr/share/emacs/26.3/etc/images and refer to it as simply
> "lxa-next". Emacs 27.1 shows nothing either way. My lxa-next.xpm appears
> similar to the native lock-broken.xpm (4.7kB vs. 4.6kB) so I
> experimented referring to that instead of mine and it worked. I also
> tested left-arrow but instead of left-arrow.xpm or pbm, it showed a very
> plain < image that doesn't exist in the images directory. It should be
> noted that there is a lock-broken.pbm but the xpm version was
> automatically selected. The icon selection mechanism of Emacs 26.3 is
> usable but could be improved by accepting an explicit icon file
> extension. That of 27.1 is unusable and, unless we can fix it, I will
> have to advise users of my library to install an older version of Emacs.

I tried to visit the XPM file you attached, and it displays okay with
both Emacs 27.1 and the current development version, at least on
MS-Windows.  So I don't see a reason why this would not work on a tool
bar.  I suggest that you post some minimal Lisp code that displays
these icons on the Emacs tool bar, starting from "emacs -Q", and then
we could try the code and see if the problem can be reproduced and
debugged.

Btw, to clarify: you are saying that your XPM icons don't work in
Emacs 27.1 both on MS-Windows and on Ubuntu?  Or only on Ubuntu?

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David McCracken <davidm <at> ixont.com>
Cc: 71162 <at> debbugs.gnu.org
Subject: Re: bug#71162: bug-gnu-emacs <at> gnu.org
Date: Sat, 25 May 2024 09:09:23 +0300

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

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> Date: Fri, 24 May 2024 12:29:49 -0700
> From: David McCracken <davidm <at> ixont.com>
> 
> I use the same icons and emacs code on Windows and Linux. In Windows it 
> works in Emacs 29.1 and 26.1 (the two I currently use but it worked in 
> older versions as well). In Ubuntu-Mate (20.54 and 22.04) it works in 
> Emacs 26.3 but not 27.1. The code I use for this particular example is
> 
> (define-key-after (default-value 'tool-bar-map)
>    [separator-4] menu-bar-separator)
> ; Linux-Emacs v25 includes pseudo-key name in the toolbar unless it is too
> ; long, which is the only way to stop this unwanted behavior.
> (tool-bar-add-item "~/icons/lxa-next"
>    'lxa-next
>    'lxa-next-reference
>    :help "LXA next reference")
> 
> In all cases except Emacs 27.1 in Linux the user icons directory is not 
> a problem. However, it is an additional problem in 27.1 under Linux. The 
> same native lock-broken.xpm that works when in the images directory and 
> referenced simply as "lock-broken" fails when moved to the user icons 
> directory and referenced as "~/icons/lock-broken". 27.1 also ignores my 
> lxa-next.xpm when moved to the images directory and referenced simply as 
> "lxa-next". Somebody hard-wired all flexibility out of this mechanism 
> after 26.3 but only in the Linux version. I initially suspected the 
> changes related to B/W pbm images, which is described in the images 
> README but I found the same README in 26.3.

If you visit (with C-x C-f) the lxa-next.xpm file in Emacs 27.1 on
Ubuntu, does it display correctly as an image?  If not, your Emacs
27.1 on Ubuntu is for some reason unable to display XPM images.

If lxa-next.xpm does display correctly on Ubuntu, then you need to
find out why adding a tool-bar button with an XPM image doesn't work
for you.  I just tried the below in "emacs-Q" (using Emacs 27.1), and
it did show the additional tool-bar button:

  (defun lxa-next ()
    (interactive)
    (message "lxa-next"))

  (tool-bar-add-item "~/icons/lxa-next"
   'lxa-next
   'lxa-next-reference
   :help "LXA next reference")

Does the above work for you in "emacs -Q" on Ubuntu?

If it works in "emacs -Q", but not in your regular sessions, then
there are some customizations, perhaps site-wide and possibly by the
Ubuntu distro, which somehow prevent this.  In the upstream sources, I
see no changes in this area.  tool-bar-add-item still ends up calling
tool-bar--image-expression, which calls find-image like this:

  (let* ((fg (face-attribute 'tool-bar :foreground))
	 (bg (face-attribute 'tool-bar :background))
	 (colors (nconc (if (eq fg 'unspecified) nil (list :foreground fg))
			(if (eq bg 'unspecified) nil (list :background bg))))
	 (xpm-spec (list :type 'xpm :file (concat icon ".xpm")))
	 (xpm-lo-spec (list :type 'xpm :file
			    (concat "low-color/" icon ".xpm")))
	 (pbm-spec (append (list :type 'pbm :file
                                 (concat icon ".pbm")) colors))
	 (xbm-spec (append (list :type 'xbm :file
                                 (concat icon ".xbm")) colors)))
    `(find-image (cond ((not (display-color-p))
			',(list pbm-spec xbm-spec xpm-lo-spec xpm-spec))
		       ((< (display-color-cells) 256)
			',(list xpm-lo-spec xpm-spec pbm-spec xbm-spec))
		       (t
			',(list xpm-spec pbm-spec xbm-spec))))))

As you see here, if your display can support at least 256 colors, the
XPM image gets preference over the other possibilities.  And
find-image searches for the image file via image-search-load-path,
which searches image-load-path, and for absolute file names like
"~/images/lxa-next" should find the file immediately regardless of the
value of image-load-path.

So if your Emacs does not have some customizations, it should find the
images without any problem.

If the problem is some Ubuntu customizations, you should take that up
with the Ubuntu distro maintainers; we here are only responsible for
the original Emacs 27.1 tarball.

> In case you are interested I have attached my complete code.

I attach it below, because you sent the response only to me in private
email (please use Reply All or "wide reply" in your future responses
to this discussion).

[linkxall.el (application/emacs-lisp, attachment)]

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

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: David McCracken <davidm <at> ixont.com>
Cc: 71162 <at> debbugs.gnu.org
Subject: Re: bug#71162: bug-gnu-emacs <at> gnu.org
Date: Sat, 25 May 2024 12:42:56 +0200

David McCracken writes:
> [Content of XPM file:]
> /* XPM */
> static char * C:\SwDev\Emacs\icons\lxa_search_fwd_xpm[] = {
> "24 24 198 2",
> "  	c None",

An XPM file is supposed to be valid C code internally.  If I cut that MS
Windows directory part, the file works for me.  You might want to
complain to the programmer of your image file editor.

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

From: David McCracken <davidm <at> ixont.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71162 <at> debbugs.gnu.org
Subject: Re: bug#71162: bug-gnu-emacs <at> gnu.org
Date: Sat, 25 May 2024 12:08:33 -0700

Thank you both for taking the time to look into this.

I use Gimp under Windows to make my icons and they all work in 
Linux-Emacs 26.1. When I open lxa-next.xpm in Linux-Emacs 26.3 (in 
Ubuntu-Mate 20.54) the icon is rendered correctly. Linux-Emacs 27.1 (in 
Ubuntu-Mate 22.04) shows it as a blank box. All systems correctly show 
my icons in the GUI. I edited lxa-next.xpm as text, completely removing 
the Windows directory, which isn't proper C code because it doesn't name 
the variable being defined. Nevertheless, the newer Linux computer's GUI 
does render it although with less saturated colors. When I include a 
variable name, "something" or "*/~/icons/lxa-next.xpm", the system 
renders it as designed. However, Emacs still shows it blank. I tried all 
of these variations in the 27.1/etc/images directory and Emacs showed 
them all blank. This did not change with emacs -q so the problem is not 
caused by my .emacs. The problem also doesn't seem to be caused by 
Ubuntu-Mate because it renders my icons correctly.

I assume that tool-bar--image-expression is located in an elc module. 
Which is it and can I get an el copy? I would like to trace it to 
determine why Linux-Emacs 27.1 refuses its own icons unless located in 
27.1/etc/images. That it refuses my icons no matter where they are 
located may be related. With some help from you all I may be able to 
find the root of both problems.

On 2024-05-24 11:09 PM, Eli Zaretskii wrote:
> [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>
>> Date: Fri, 24 May 2024 12:29:49 -0700
>> From: David McCracken <davidm <at> ixont.com>
>>
>> I use the same icons and emacs code on Windows and Linux. In Windows it
>> works in Emacs 29.1 and 26.1 (the two I currently use but it worked in
>> older versions as well). In Ubuntu-Mate (20.54 and 22.04) it works in
>> Emacs 26.3 but not 27.1. The code I use for this particular example is
>>
>> (define-key-after (default-value 'tool-bar-map)
>>     [separator-4] menu-bar-separator)
>> ; Linux-Emacs v25 includes pseudo-key name in the toolbar unless it is too
>> ; long, which is the only way to stop this unwanted behavior.
>> (tool-bar-add-item "~/icons/lxa-next"
>>     'lxa-next
>>     'lxa-next-reference
>>     :help "LXA next reference")
>>
>> In all cases except Emacs 27.1 in Linux the user icons directory is not
>> a problem. However, it is an additional problem in 27.1 under Linux. The
>> same native lock-broken.xpm that works when in the images directory and
>> referenced simply as "lock-broken" fails when moved to the user icons
>> directory and referenced as "~/icons/lock-broken". 27.1 also ignores my
>> lxa-next.xpm when moved to the images directory and referenced simply as
>> "lxa-next". Somebody hard-wired all flexibility out of this mechanism
>> after 26.3 but only in the Linux version. I initially suspected the
>> changes related to B/W pbm images, which is described in the images
>> README but I found the same README in 26.3.
> If you visit (with C-x C-f) the lxa-next.xpm file in Emacs 27.1 on
> Ubuntu, does it display correctly as an image?  If not, your Emacs
> 27.1 on Ubuntu is for some reason unable to display XPM images.
>
> If lxa-next.xpm does display correctly on Ubuntu, then you need to
> find out why adding a tool-bar button with an XPM image doesn't work
> for you.  I just tried the below in "emacs-Q" (using Emacs 27.1), and
> it did show the additional tool-bar button:
>
>    (defun lxa-next ()
>      (interactive)
>      (message "lxa-next"))
>
>    (tool-bar-add-item "~/icons/lxa-next"
>     'lxa-next
>     'lxa-next-reference
>     :help "LXA next reference")
>
> Does the above work for you in "emacs -Q" on Ubuntu?
>
> If it works in "emacs -Q", but not in your regular sessions, then
> there are some customizations, perhaps site-wide and possibly by the
> Ubuntu distro, which somehow prevent this.  In the upstream sources, I
> see no changes in this area.  tool-bar-add-item still ends up calling
> tool-bar--image-expression, which calls find-image like this:
>
>    (let* ((fg (face-attribute 'tool-bar :foreground))
> 	 (bg (face-attribute 'tool-bar :background))
> 	 (colors (nconc (if (eq fg 'unspecified) nil (list :foreground fg))
> 			(if (eq bg 'unspecified) nil (list :background bg))))
> 	 (xpm-spec (list :type 'xpm :file (concat icon ".xpm")))
> 	 (xpm-lo-spec (list :type 'xpm :file
> 			    (concat "low-color/" icon ".xpm")))
> 	 (pbm-spec (append (list :type 'pbm :file
>                                   (concat icon ".pbm")) colors))
> 	 (xbm-spec (append (list :type 'xbm :file
>                                   (concat icon ".xbm")) colors)))
>      `(find-image (cond ((not (display-color-p))
> 			',(list pbm-spec xbm-spec xpm-lo-spec xpm-spec))
> 		       ((< (display-color-cells) 256)
> 			',(list xpm-lo-spec xpm-spec pbm-spec xbm-spec))
> 		       (t
> 			',(list xpm-spec pbm-spec xbm-spec))))))
>
> As you see here, if your display can support at least 256 colors, the
> XPM image gets preference over the other possibilities.  And
> find-image searches for the image file via image-search-load-path,
> which searches image-load-path, and for absolute file names like
> "~/images/lxa-next" should find the file immediately regardless of the
> value of image-load-path.
>
> So if your Emacs does not have some customizations, it should find the
> images without any problem.
>
> If the problem is some Ubuntu customizations, you should take that up
> with the Ubuntu distro maintainers; we here are only responsible for
> the original Emacs 27.1 tarball.
>
>> In case you are interested I have attached my complete code.
> I attach it below, because you sent the response only to me in private
> email (please use Reply All or "wide reply" in your future responses
> to this discussion).
>

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

From: David McCracken <davidm <at> ixont.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71162 <at> debbugs.gnu.org
Subject: Re: bug#71162: bug-gnu-emacs <at> gnu.org
Date: Sat, 25 May 2024 13:04:34 -0700

Sorry about my previous question about finding the source of 
tool-bar--image-expression. tool-bar.el.gz was easy to find. The 26.3 
and 27.1 versions are not identical but the differences are unrelated to 
either of the problems I have encountered. I am going to instrument the 
function to try to track down the problem but I suspect that Ubuntu is 
the cause. Replacing Emacs 27.1 with 26.3 without changing the OS would 
answer the question but I don't know how to do this. I always just used 
apt-get install emacs. How can I install a downrev?

On 2024-05-23 11:15 PM, Eli Zaretskii wrote:
>> Date: Thu, 23 May 2024 21:08:24 -0700
>> From: David McCracken <davidm <at> ixont.com>
>>
>> I have developed a library that includes a toolbar with custom icons. It
>> works in all versions of Emacs in Windows and in Emacs version 26.3
>> under Ubuntu-Mate 20.54 but the toolbar doesn't work in Emacs 27.1 under
>> Ubuntu-Mate 22.04. In my preferred configuration I put my icons under
>> the user home directory so that this doesn't change if Emacs is
>> updated. My library accesses this with e.g.
>> (tool-bar-add-item "~/icons/lxa-next"
>> to use my lxa-next.xpm icon. In Emacs 26.3 it also works to put my icon
>> in /usr/share/emacs/26.3/etc/images and refer to it as simply
>> "lxa-next". Emacs 27.1 shows nothing either way. My lxa-next.xpm appears
>> similar to the native lock-broken.xpm (4.7kB vs. 4.6kB) so I
>> experimented referring to that instead of mine and it worked. I also
>> tested left-arrow but instead of left-arrow.xpm or pbm, it showed a very
>> plain < image that doesn't exist in the images directory. It should be
>> noted that there is a lock-broken.pbm but the xpm version was
>> automatically selected. The icon selection mechanism of Emacs 26.3 is
>> usable but could be improved by accepting an explicit icon file
>> extension. That of 27.1 is unusable and, unless we can fix it, I will
>> have to advise users of my library to install an older version of Emacs.
> I tried to visit the XPM file you attached, and it displays okay with
> both Emacs 27.1 and the current development version, at least on
> MS-Windows.  So I don't see a reason why this would not work on a tool
> bar.  I suggest that you post some minimal Lisp code that displays
> these icons on the Emacs tool bar, starting from "emacs -Q", and then
> we could try the code and see if the problem can be reproduced and
> debugged.
>
> Btw, to clarify: you are saying that your XPM icons don't work in
> Emacs 27.1 both on MS-Windows and on Ubuntu?  Or only on Ubuntu?
>
> Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David McCracken <davidm <at> ixont.com>
Cc: 71162 <at> debbugs.gnu.org
Subject: Re: bug#71162: bug-gnu-emacs <at> gnu.org
Date: Sun, 26 May 2024 07:44:21 +0300

> Date: Sat, 25 May 2024 12:08:33 -0700
> Cc: 71162 <at> debbugs.gnu.org
> From: David McCracken <davidm <at> ixont.com>
> 
> I use Gimp under Windows to make my icons and they all work in 
> Linux-Emacs 26.1. When I open lxa-next.xpm in Linux-Emacs 26.3 (in 
> Ubuntu-Mate 20.54) the icon is rendered correctly. Linux-Emacs 27.1 (in 
> Ubuntu-Mate 22.04) shows it as a blank box. All systems correctly show 
> my icons in the GUI. I edited lxa-next.xpm as text, completely removing 
> the Windows directory, which isn't proper C code because it doesn't name 
> the variable being defined. Nevertheless, the newer Linux computer's GUI 
> does render it although with less saturated colors. When I include a 
> variable name, "something" or "*/~/icons/lxa-next.xpm", the system 
> renders it as designed. However, Emacs still shows it blank. I tried all 
> of these variations in the 27.1/etc/images directory and Emacs showed 
> them all blank. This did not change with emacs -q so the problem is not 
> caused by my .emacs. The problem also doesn't seem to be caused by 
> Ubuntu-Mate because it renders my icons correctly.

Sorry, I don't understand.  If you do the following on Ubuntu with
Emacs 27.1:

  emacs -Q
  C-x C-f ~/icons/lxa-next.xpm RET

does Emacs 27.1 on Ubuntu display the image, or does it display an
empty box?  If the latter, the problem is that Emacs 27.1 on Ubuntu
that you have installed is not capable of showing XPM images
correctly.  IOW, in that case the problem is not related to the tool
bar, it is related to the general inability of displaying XPM images
in that version of Emacs.

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

From: David McCracken <davidm <at> ixont.com>
To: 71162 <at> debbugs.gnu.org
Subject: In Linux Emacs 27.1 rejects custom toolbar icons
Date: Sun, 26 May 2024 13:54:07 -0700

I decided that I could test 26.3 on the newer Ubuntu by copying some of 
the Emacs files from the other computer. I copied the emacs executable 
(located in /etc/alternatives/emacs pointed to by /usr/bin/emacs 
symlink) and recursively copied /usr/share/emacs/26.3 to 
/usr/share/emacs. I didn't change /usr/share/emacs/site-lisp or any of 
the files in /etc/emacs or usr/lib/emacs. Directly invoking the 26.3 
executable revealed that it wanted 
/usr/lib/x86_64-linux-gnu/libotf.so.0. The 27.1 installation has only 
libotf.so.1 and libotf.so.1.0.0, so I copied libotf.so.0 into the 
directory. Then 26.3 ran and correctly displayed my toolbar icons 
located in ~/icons. Unlike the 27.1 bug report, in this case the 
reporter does not show Recent messages Invalid XPM3 file.

To investigate whether the problems are caused by libotf.so, I copied 
libotf.so.0 over libotf.so.1 but then emacs 27.1 complained about a 
missing symbol definition. I did the inverse, copying libotf.so.1 over 
libotf.so.0. Emacs 26.3 was able to run with this. It continued to show 
my icons and not report the files as invalid. Therefore, the root of the 
problems is either in the emacs executable or /usr/share/emacs/27.1.

In my Windows computer with Emacs 29.1 the bug reporter does not 
complain about my icon files. The name of the char array in the xpm file 
seems to be immaterial. I tried many alternatives to * filespec, 
including simply filespec and blank, and nothing changed the 27.1 bug 
report and failure to display the icons. I tested these alternatives in 
the Windows computer with Emacs 29.1 and they didn't change anything. I 
think this is essentially a comment, especially considering that 
definining an unnamed array is not legal in C. Even if this were a 
problem, it would not account for why Linux-Emacs 27.1 rejects its own 
xpm files if located anywhere but its own images directory.

Although I would like to help get to the bottom of these problems, I 
would still like to know how to install an Emacs downrev in Linux. It is 
easy in Windows since all versions are available in zip files that I can 
unzip anywhere I want.

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

From: David McCracken <davidm <at> ixont.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71162 <at> debbugs.gnu.org
Subject: Re: bug#71162: bug-gnu-emacs <at> gnu.org
Date: Sun, 26 May 2024 21:16:19 -0700

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

grep -r XPM3 * in /usr/share/emacs shows etc/PROBLEMS:** macOS doesn't 
come with libxpm, so only XPM3 is supported. This subservience  to Apple 
contradicts the general principle of open source. However, we can adapt 
to it. sudo install xpmutils installs sxpm, which can convert XPM 1 and 
2 to 3. sxpm --help is inscrutable. sxpm /file/.xpm - o /file/.xpm 
changes /file/.xpm to XPM3. When this is applied to the icon files, 
emacs 27.1 in Linux correctly uses them in the toolbar even when they 
are located in ~/icons.

Many thanks to Benjamin Riefenstahl and Eli Zaretskii for helping me to 
resolve this problem.

On 2024-05-23 11:15 PM, Eli Zaretskii wrote:
>> Date: Thu, 23 May 2024 21:08:24 -0700
>> From: David McCracken<davidm <at> ixont.com>
>>
>> I have developed a library that includes a toolbar with custom icons. It
>> works in all versions of Emacs in Windows and in Emacs version 26.3
>> under Ubuntu-Mate 20.54 but the toolbar doesn't work in Emacs 27.1 under
>> Ubuntu-Mate 22.04. In my preferred configuration I put my icons under
>> the user home directory so that this doesn't change if Emacs is
>> updated. My library accesses this with e.g.
>> (tool-bar-add-item "~/icons/lxa-next"
>> to use my lxa-next.xpm icon. In Emacs 26.3 it also works to put my icon
>> in /usr/share/emacs/26.3/etc/images and refer to it as simply
>> "lxa-next". Emacs 27.1 shows nothing either way. My lxa-next.xpm appears
>> similar to the native lock-broken.xpm (4.7kB vs. 4.6kB) so I
>> experimented referring to that instead of mine and it worked. I also
>> tested left-arrow but instead of left-arrow.xpm or pbm, it showed a very
>> plain < image that doesn't exist in the images directory. It should be
>> noted that there is a lock-broken.pbm but the xpm version was
>> automatically selected. The icon selection mechanism of Emacs 26.3 is
>> usable but could be improved by accepting an explicit icon file
>> extension. That of 27.1 is unusable and, unless we can fix it, I will
>> have to advise users of my library to install an older version of Emacs.
> I tried to visit the XPM file you attached, and it displays okay with
> both Emacs 27.1 and the current development version, at least on
> MS-Windows.  So I don't see a reason why this would not work on a tool
> bar.  I suggest that you post some minimal Lisp code that displays
> these icons on the Emacs tool bar, starting from "emacs -Q", and then
> we could try the code and see if the problem can be reproduced and
> debugged.
>
> Btw, to clarify: you are saying that your XPM icons don't work in
> Emacs 27.1 both on MS-Windows and on Ubuntu?  Or only on Ubuntu?
>
> Thanks.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David McCracken <davidm <at> ixont.com>
Cc: 71162-done <at> debbugs.gnu.org
Subject: Re: bug#71162: In Linux Emacs 27.1 rejects custom toolbar icons
Date: Mon, 27 May 2024 14:20:39 +0300

> Date: Sun, 26 May 2024 21:16:19 -0700
> Cc: 71162 <at> debbugs.gnu.org
> From: David McCracken <davidm <at> ixont.com>
> 
> grep -r XPM3 * in /usr/share/emacs shows etc/PROBLEMS:** macOS doesn't come with libxpm, so only XPM3
> is supported. This subservience  to Apple contradicts the general principle of open source. However, we can
> adapt to it. sudo install xpmutils installs sxpm, which can convert XPM 1 and 2 to 3. sxpm --help is inscrutable.
> sxpm file.xpm - o file.xpm changes file.xpm to XPM3. When this is applied to the icon files, emacs 27.1 in Linux
> correctly uses them in the toolbar even when they are located in ~/icons.
> 
> Many thanks to Benjamin Riefenstahl and Eli Zaretskii for helping me to resolve this problem.

OK, so I'm now closing this bug.

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

From: David McCracken <davidm <at> ixont.com>
To: 71162 <at> debbugs.gnu.org
Subject: Linux-Emacs > 26 icons
Date: Mon, 27 May 2024 20:56:19 -0700

The issue of Linux-Emacs 27.1 not accepting its own icons in ~/icons was 
coincidental. When my icons were not appearing, I experimented by 
copying lock-broken.xpm to ~/icons and changing my library to refer to 
it. I did this directly in /usr/share/emacs/site-lisp so sudo was 
required. Normally, when I do superuser work I log in as root and am 
well aware that this has its own home directory. I had forgotten that 
sudo doesn't just grant extra priviledge but temporarily makes the user 
root, for whom ~/icons doesn't exist.

The issue of the Windows directory reference in my xpm files was also 
just a coincidence. The real problem is that Linux-Emacs 27.1 demands 
XPM3 even though the system has no problem with earlier versions. 
Comparing different versions of the same icon reveals that XPM3 syntax 
is very different from XPM2. I didn't want to have to provide different 
versions of the icons for different systems so I tested the XPM3 
translations on the computers that were not having trouble with XPM2 and 
they worked.

Previous Next

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