Subject: Re: bug#60669: Linux Emacs 27.1 custom toolbar icons

From: David McCracken <[email-masked]>
Date: Thu, 7 Sep 2023 21:07:59 -0700

I could not do what you asked because I restored an earlier version of 
Ubuntu (20.04) and Emacs (26.3) to verify that it was a new problem. The 
problem did not exist in the earlier versions. I wasn't going to 
deliberate corrupt my computer again just for a little information.

On 2023-09-03 2:41 AM, Stefan Kangas wrote:
> Eli Zaretskii <[email-masked]> writes:
>
>>> Date: Sun, 8 Jan 2023 13:01:26 -0800
>>> From: David McCracken <[email-masked]>
>>>
>>> The Emacs 27.1 provided (apt-get install) by Ubuntu 22.04 reduces
>>> support for custom toolbar icons. It only works with B/W pbm files and
>>> only if located in /usr/share/emacs/27.1/etc/images and only if there
>>> isn't an xpm file with the same base name. i.e. name.pbm works but not
>>> if there is a name.xpm in the directory. If these conditions are not met
>>> nothing is displayed.
>>>
>>> This does not seem to be baked into Emacs 27.1 because these
>>> restrictions don't exist in Windows Emacs 27.1. They are also not
>>> inherent in Linux because they don't exist in Linux Emacs 26.1.
>>>
>>> There are two serious problems with these seemingly unnecessary changes.
>>> B/W icons reduce not just the aesthetic quality but also subtle visual
>>> clues that help an icon convey its meaning. Accepting only icons in the
>>> version-numbered installation directory means that custom icons are
>>> wiped out by upgrading Emacs.
>>>
>>> The installer program I provide with my Emacs library stores its (xpm)
>>> icons in ~/icons (a directory created by my installer). My library
>>> accesses these by e.g.
>>> (tool-bar-add-item "~/icons/lxa-pin"
>>> Linux Emacs 27.1 is the only version in which this does not work. To
>>> test whether it does not like that the directory is relatively insecure,
>>> I tried moving my icons to /usr/local but they were still ignored. In
>>> all other versions, adding the xpm extension to the reference causes it
>>> to fail but I tested this anyway and it accomplished nothing.
>> Can you please show a reproducible recipe, starting from "emacs -Q",
>> that exhibits the problem you are describing?  I don't think I
>> understand what exactly doesn't work in your case.
>>
>> Also, please use "M-x report-emacs-bug" to post the details, as that
>> command collects important details about the Emacs build configuration
>> that make investigation easier.
>>
>> Thanks.
> More information was requested, but none was given within 9 months, so
> I'm closing this bug.  If this is still an issue, please reply to this
> email (use "Reply to all" in your email client) and we can reopen the
> bug report.