bug#71162:

[David McCracken <davidm@ixont.com>]

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@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).
>