GNU bug report logs -
#60669
Linux Emacs 27.1 custom toolbar icons
Previous Next
Reported by: David McCracken <davidm <at> ixont.com>
Date: Sun, 8 Jan 2023 23:40:02 UTC
Severity: normal
Tags: moreinfo
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60669 in the body.
You can then email your comments to 60669 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60669
; Package
emacs
.
(Sun, 08 Jan 2023 23:40:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
David McCracken <davidm <at> ixont.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 08 Jan 2023 23:40:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60669
; Package
emacs
.
(Mon, 09 Jan 2023 03:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 60669 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 8 Jan 2023 13:01:26 -0800
> From: David McCracken <davidm <at> ixont.com>
>
> 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.
Added tag(s) moreinfo.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 10 Jan 2023 09:09:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
You have taken responsibility.
(Sun, 03 Sep 2023 09:42:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
David McCracken <davidm <at> ixont.com>
:
bug acknowledged by developer.
(Sun, 03 Sep 2023 09:42:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 60669-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sun, 8 Jan 2023 13:01:26 -0800
>> From: David McCracken <davidm <at> ixont.com>
>>
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60669
; Package
emacs
.
(Fri, 08 Sep 2023 04:09:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 60669-done <at> debbugs.gnu.org (full text, mbox):
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 <eliz <at> gnu.org> writes:
>
>>> Date: Sun, 8 Jan 2023 13:01:26 -0800
>>> From: David McCracken <davidm <at> ixont.com>
>>>
>>> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 06 Oct 2023 11:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 217 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.