GNU bug report logs -
#77917
31.0.50; [PATCH] Stop using the "stop" sign for all warning levels
Previous Next
Reported by: Protesilaos Stavrou <prot <at> protesilaos.com>
Date: Sat, 19 Apr 2025 07:25:02 UTC
Severity: normal
Tags: patch
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
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 77917 in the body.
You can then email your comments to 77917 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#77917; Package
emacs.
(Sat, 19 Apr 2025 07:25:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Protesilaos Stavrou <prot <at> protesilaos.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 19 Apr 2025 07:25:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dear maintainers,
The *Warnings* buffer uses the same "stop" sign for "warning" and
"error" level warnings. This makes it hard to quickly scan the buffer
for actual errors.
I attach a patch that uses a different icon for "warning" than for
"error" or "emergency".
All the best,
Protesilaos (or simply "Prot")
[0001-Stop-using-the-stop-sign-for-all-warning-levels.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 19 Apr 2025 08:30:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 19 Apr 2025 08:14:00 +0300
> From: Protesilaos Stavrou <prot <at> protesilaos.com>
>
> The *Warnings* buffer uses the same "stop" sign for "warning" and
> "error" level warnings. This makes it hard to quickly scan the buffer
> for actual errors.
The sign is not for Warning or Error, it's for _disabling_ the
message. That's why it's the same sign.
Why can't one search by using the text, not the sign?
> I attach a patch that uses a different icon for "warning" than for
> "error" or "emergency".
That's wrong, IMO, see above.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 19 Apr 2025 09:18:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 77917 <at> debbugs.gnu.org (full text, mbox):
On 2025-04-19 11:29, Eli Zaretskii wrote:
>> Date: Sat, 19 Apr 2025 08:14:00 +0300
>> From: Protesilaos Stavrou <prot <at> protesilaos.com>
>>
>> The *Warnings* buffer uses the same "stop" sign for "warning" and
>> "error" level warnings. This makes it hard to quickly scan the buffer
>> for actual errors.
>
> The sign is not for Warning or Error, it's for _disabling_ the
> message. That's why it's the same sign.
>
> Why can't one search by using the text, not the sign?
>
>> I attach a patch that uses a different icon for "warning" than for
>> "error" or "emergency".
>
> That's wrong, IMO, see above.
I see, thank you!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 19 Apr 2025 23:34:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The sign is not for Warning or Error, it's for _disabling_ the
> message. That's why it's the same sign.
This will be confusing Emacs users *forever*, IMO.
You keep saying we should wait until people get used to these "buttons",
but that is not a good idea. If nobody else, some new users will always
struggle, as the design of these buttons is inherently flawed. I know
of no mature software that uses Emojis this way, which makes this UI not
discoverable. We should *default* to text buttons, e.g.
[Suppress], [Hide], or [Disable].
If someone likes emoticons better than text labels, it should be them to
customize. We should *default* to standard, battle-proven, and thus
discoverable, UI elements.
Rudy
--
"One can begin to reason only when a clear picture has been formed in
the imagination." --- Walter Warwick Sawyer, Mathematician's Delight,
1943
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 20 Apr 2025 06:27:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Cc: 77917 <at> debbugs.gnu.org
> Date: Sun, 20 Apr 2025 01:33:08 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > The sign is not for Warning or Error, it's for _disabling_ the
> > message. That's why it's the same sign.
>
> This will be confusing Emacs users *forever*, IMO.
>
> You keep saying we should wait until people get used to these "buttons",
> but that is not a good idea.
That's my opinion, yes. It's based on a lot of gray hair with user
expectations. But I also said that people should feel free to ignore
my opinion on this, if they are certain changing the appearance will
produce better results. So I'm not sure why you are still arguing.
> We should *default* to text buttons, e.g.
>
> [Suppress], [Hide], or [Disable].
That still could confuse: suppress what? hide what?
Like I said: there's no clear winner here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 20 Apr 2025 06:28:07 GMT)
Full text and
rfc822 format available.
Message #20 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>> The *Warnings* buffer uses the same "stop" sign for "warning" and
>> "error" level warnings. This makes it hard to quickly scan the buffer
>> for actual errors.
>
> The sign is not for Warning or Error, it's for _disabling_ the
> message. That's why it's the same sign.
The icon at the beginning of a warning/error is very useful
to help separating one warning/error from another, especially
for many very long multi-line messages. But the button for
disabling them like [Disable] could be added at the end of messages.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 20 Apr 2025 06:47:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> The sign is not for Warning or Error, it's for _disabling_ the
>> message. That's why it's the same sign.
>
> The icon at the beginning of a warning/error is very useful
> to help separating one warning/error from another, especially
> for many very long multi-line messages. But the button for
> disabling them like [Disable] could be added at the end of messages.
+1
I'd also like to add that it is important that [Disable] (or any other
text) is highlighted as a link. This really helps to figure out that one
can interact with that text. The existing "stop" sign lack such indication.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 20 Apr 2025 08:26:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77917 <at> debbugs.gnu.org, Protesilaos Stavrou
> <prot <at> protesilaos.com>
> Date: Sun, 20 Apr 2025 06:45:02 +0000
>
> Juri Linkov <juri <at> linkov.net> writes:
>
> >> The sign is not for Warning or Error, it's for _disabling_ the
> >> message. That's why it's the same sign.
> >
> > The icon at the beginning of a warning/error is very useful
> > to help separating one warning/error from another, especially
> > for many very long multi-line messages. But the button for
> > disabling them like [Disable] could be added at the end of messages.
>
> +1
> I'd also like to add that it is important that [Disable] (or any other
> text) is highlighted as a link. This really helps to figure out that one
> can interact with that text. The existing "stop" sign lack such indication.
Why link and not a button? The latter would be more self-explanatory,
IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 20 Apr 2025 08:34:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> +1
>> I'd also like to add that it is important that [Disable] (or any other
>> text) is highlighted as a link. This really helps to figure out that one
>> can interact with that text. The existing "stop" sign lack such indication.
>
> Why link and not a button? The latter would be more self-explanatory,
> IMO.
Agree. I just recall it being a link in the past, before ⛔ was introduced.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 20 Apr 2025 08:59:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 77917 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு ஏப்ரல் 20, 2025] Juri Linkov wrote:
>>> The *Warnings* buffer uses the same "stop" sign for "warning" and
>>> "error" level warnings. This makes it hard to quickly scan the buffer
>>> for actual errors.
>>
>> The sign is not for Warning or Error, it's for _disabling_ the
>> message. That's why it's the same sign.
>
> The icon at the beginning of a warning/error is very useful
> to help separating one warning/error from another, especially
> for many very long multi-line messages. But the button for
> disabling them like [Disable] could be added at the end of messages.
Is my memory failing me, or was there such a button before the entire
emoji thing was added? I remember using said button to suppress
warnings that would show up in the early days of native compilation.
(This is how I learnt that the emoji could also be used to suppress
warning BTW).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 22 Apr 2025 02:07:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Ihor Radchenko <yantar92 <at> posteo.net> writes:
> Juri Linkov <juri <at> linkov.net> writes:
>
>>> The sign is not for Warning or Error, it's for _disabling_ the
>>> message. That's why it's the same sign.
>>
>> The icon at the beginning of a warning/error is very useful
>> to help separating one warning/error from another, especially
>> for many very long multi-line messages. But the button for
>> disabling them like [Disable] could be added at the end of messages.
>
> +1
> I'd also like to add that it is important that [Disable] (or any other
> text) is highlighted as a link. This really helps to figure out that one
> can interact with that text. The existing "stop" sign lack such indication.
FWIW, I think changing the icon to something not meaning "stop" would be
better, and I'd prefer that the button looks like a regular text button.
I think this improvement is worth making now, and possibly even
backporting to emacs-30. I consider this a usability bug.
I think if we want our users to get used to something like this, let's
at least make it not actively confusing.
My two cents.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 22 Apr 2025 02:31:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> The icon at the beginning of a warning/error is very useful
> to help separating one warning/error from another, especially
> for many very long multi-line messages. But the button for
> disabling them like [Disable] could be added at the end of messages.
+1 [Disable], [Suppress], [Hide], or the like.
And as Ihor says, the button should be fontified as such.
Then, nobody will wonder what do to.
Rudy
--
"Simplicity is complexity resolved."
--- Constantin Brâncuși, 1876-1957
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 03 May 2025 08:18:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Protesilaos Stavrou <prot <at> protesilaos.com>:
bug acknowledged by developer.
(Sat, 03 May 2025 08:18:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 77917-done <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 19 Apr 2025 11:55:22 +0300
> From: Protesilaos Stavrou <prot <at> protesilaos.com>
> Cc: 77917 <at> debbugs.gnu.org
>
> On 2025-04-19 11:29, Eli Zaretskii wrote:
> >> Date: Sat, 19 Apr 2025 08:14:00 +0300
> >> From: Protesilaos Stavrou <prot <at> protesilaos.com>
> >>
> >> The *Warnings* buffer uses the same "stop" sign for "warning" and
> >> "error" level warnings. This makes it hard to quickly scan the buffer
> >> for actual errors.
> >
> > The sign is not for Warning or Error, it's for _disabling_ the
> > message. That's why it's the same sign.
> >
> > Why can't one search by using the text, not the sign?
> >
> >> I attach a patch that uses a different icon for "warning" than for
> >> "error" or "emergency".
> >
> > That's wrong, IMO, see above.
>
> I see, thank you!
No further comments, so I'm now closing this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 09:10:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 77917-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> I attach a patch that uses a different icon for "warning" than for
>> >> "error" or "emergency".
>> >
>> > That's wrong, IMO, see above.
>>
>> I see, thank you!
>
> No further comments, so I'm now closing this bug.
But there have been alternative suggestions.
Are they all discarded?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 10:19:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Protesilaos Stavrou <prot <at> protesilaos.com>, 77917-done <at> debbugs.gnu.org
> Date: Sat, 03 May 2025 09:08:22 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> >> I attach a patch that uses a different icon for "warning" than for
> >> >> "error" or "emergency".
> >> >
> >> > That's wrong, IMO, see above.
> >>
> >> I see, thank you!
> >
> > No further comments, so I'm now closing this bug.
>
> But there have been alternative suggestions.
> Are they all discarded?
I don't see any need to keep a bug open if no one is working on doing
anything with it. If there's a suggestion for a change that is
agreed-upon, let's see it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 10:29:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> But there have been alternative suggestions.
>> Are they all discarded?
>
> I don't see any need to keep a bug open if no one is working on doing
> anything with it. If there's a suggestion for a change that is
> agreed-upon, let's see it.
I am probably going a bit off-topic, but I cannot help but wonder how
people looking to contribute to Emacs can find things to work on if
unsolved bugs are closed if they are not immediately worked on.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 10:41:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> But there have been alternative suggestions.
>> Are they all discarded?
>
> ... If there's a suggestion for a change that is
> agreed-upon, let's see it.
I thought that we converged to using a button, didn't we?
At least, that suggestion was not objected by anyone.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 11:14:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: prot <at> protesilaos.com, 77917 <at> debbugs.gnu.org
> Date: Sat, 03 May 2025 10:27:09 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> But there have been alternative suggestions.
> >> Are they all discarded?
> >
> > I don't see any need to keep a bug open if no one is working on doing
> > anything with it. If there's a suggestion for a change that is
> > agreed-upon, let's see it.
>
> I am probably going a bit off-topic, but I cannot help but wonder how
> people looking to contribute to Emacs can find things to work on if
> unsolved bugs are closed if they are not immediately worked on.
Closing a bug doesn't make it invisible. And reopening a bug is easy.
So I don't really understand these comments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 11:18:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: prot <at> protesilaos.com, 77917 <at> debbugs.gnu.org
> Date: Sat, 03 May 2025 10:38:59 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> But there have been alternative suggestions.
> >> Are they all discarded?
> >
> > ... If there's a suggestion for a change that is
> > agreed-upon, let's see it.
>
> I thought that we converged to using a button, didn't we?
> At least, that suggestion was not objected by anyone.
I don't see any code changes posted to that effect. Without a patch,
this leads nowhere.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 11:20:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I am probably going a bit off-topic, but I cannot help but wonder how
>> people looking to contribute to Emacs can find things to work on if
>> unsolved bugs are closed if they are not immediately worked on.
>
> Closing a bug doesn't make it invisible. And reopening a bug is easy.
>
> So I don't really understand these comments.
I vaguely recall that SystemCrafters once claimed that you suggested to
use debbugs tracker to hunt for things that can be fixed.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
Won't closing a bug eliminate it from that listing?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sat, 03 May 2025 11:32:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: prot <at> protesilaos.com, 77917 <at> debbugs.gnu.org
> Date: Sat, 03 May 2025 11:18:25 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> I am probably going a bit off-topic, but I cannot help but wonder how
> >> people looking to contribute to Emacs can find things to work on if
> >> unsolved bugs are closed if they are not immediately worked on.
> >
> > Closing a bug doesn't make it invisible. And reopening a bug is easy.
> >
> > So I don't really understand these comments.
>
> I vaguely recall that SystemCrafters once claimed that you suggested to
> use debbugs tracker to hunt for things that can be fixed.
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
>
> Won't closing a bug eliminate it from that listing?
Using package=emacs is a bad idea anyway, IME, as it hides some bugs
(for reasons I have never understood).
The Debbugs search at https://debbugs.gnu.org/cgi/search.cgi certainly
doesn't eliminate such bugs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 12:36:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 03 May 2025 14:17:35 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> Cc: prot <at> protesilaos.com, 77917 <at> debbugs.gnu.org
>> Date: Sat, 03 May 2025 10:38:59 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> But there have been alternative suggestions.
>> >> Are they all discarded?
>> >
>> > ... If there's a suggestion for a change that is
>> > agreed-upon, let's see it.
>>
>> I thought that we converged to using a button, didn't we?
>> At least, that suggestion was not objected by anyone.
Eli> I don't see any code changes posted to that effect. Without a patch,
Eli> this leads nowhere.
Since I feel guilty about ever suggesting this feature in the first
place, how about (moving it to the end of the line is possible, if desired):
diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 6c77d57a6ba..3e6128f2511 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -324,8 +324,10 @@ display-warning
;; Don't output the button when doing batch compilation
;; and similar.
(unless (or noninteractive (eq type 'bytecomp))
- (insert (buttonize (icon-string 'warnings-suppress)
- #'warnings-suppress type)
+ (insert (buttonize "[Suppress?]"
+ #'warnings-suppress
+ type
+ "Click to suppress this warning type")
" "))
(if warning-prefix-function
(setq level-info (funcall warning-prefix-function
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 16:41:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> Since I feel guilty about ever suggesting this feature in the first
> place, how about (moving it to the end of the line is possible, if desired):
>
> @@ -324,8 +324,10 @@ display-warning
> ;; Don't output the button when doing batch compilation
> ;; and similar.
> (unless (or noninteractive (eq type 'bytecomp))
> - (insert (buttonize (icon-string 'warnings-suppress)
> - #'warnings-suppress type)
> + (insert (buttonize "[Suppress?]"
> + #'warnings-suppress
> + type
> + "Click to suppress this warning type")
The current icon at the beginning of the line helps
to direct user's attention to the warning.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 16:45:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> - (insert (buttonize (icon-string 'warnings-suppress)
>> - #'warnings-suppress type)
>> + (insert (buttonize "[Suppress?]"
>> + #'warnings-suppress
>> + type
>> + "Click to suppress this warning type")
>
> The current icon at the beginning of the line helps
> to direct user's attention to the warning.
Then, what about
+ (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
+ #'warnings-suppress
+ type
+ "Click to suppress this warning type")
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 17:07:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>> - (insert (buttonize (icon-string 'warnings-suppress)
>>> - #'warnings-suppress type)
>>> + (insert (buttonize "[Suppress?]"
>>> + #'warnings-suppress
>>> + type
>>> + "Click to suppress this warning type")
>>
>> The current icon at the beginning of the line helps
>> to direct user's attention to the warning.
>
> Then, what about
>
> + (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
> + #'warnings-suppress
> + type
> + "Click to suppress this warning type")
This adds too much visual clutter to users who don't need to click this button.
A better place for this button would be at the end.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 17:20:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> Then, what about
>>
>> + (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
>> + #'warnings-suppress
>> + type
>> + "Click to suppress this warning type")
>
> This adds too much visual clutter to users who don't need to click this button.
> A better place for this button would be at the end.
Then, maybe partially revert 0db604a9149, resurrecting
- ;; Don't output the buttons when doing batch compilation
- ;; and similar.
- (unless (or noninteractive (eq type 'bytecomp))
- (insert " ")
- (insert-button "Disable showing"
- 'type 'warning-suppress-warning
- 'warning-type type)
- (insert " ")
- (insert-button "Disable logging"
- 'type 'warning-suppress-log-warning
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 17:28:01 GMT)
Full text and
rfc822 format available.
Message #85 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Robert Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com
> Date: Mon, 05 May 2025 16:43:17 +0000
>
> Juri Linkov <juri <at> linkov.net> writes:
>
> >> - (insert (buttonize (icon-string 'warnings-suppress)
> >> - #'warnings-suppress type)
> >> + (insert (buttonize "[Suppress?]"
> >> + #'warnings-suppress
> >> + type
> >> + "Click to suppress this warning type")
> >
> > The current icon at the beginning of the line helps
> > to direct user's attention to the warning.
>
> Then, what about
>
> + (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
> + #'warnings-suppress
> + type
> + "Click to suppress this warning type")
May I suggest to look at how other applications handle such
situations, i.e. when a message is shown and the user is given a
capability of disabling it? Maybe that way we will find
implementation ideas that are both familiar to users and look nicer?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 18:55:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>> Then, what about
>>>
>>> + (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
>>> + #'warnings-suppress
>>> + type
>>> + "Click to suppress this warning type")
>>
>> This adds too much visual clutter to users who don't need to click this button.
>> A better place for this button would be at the end.
>
> Then, maybe partially revert 0db604a9149, resurrecting
>
> - ;; Don't output the buttons when doing batch compilation
> - ;; and similar.
> - (unless (or noninteractive (eq type 'bytecomp))
> - (insert " ")
> - (insert-button "Disable showing"
> - 'type 'warning-suppress-warning
> - 'warning-type type)
> - (insert " ")
> - (insert-button "Disable logging"
> - 'type 'warning-suppress-log-warning
Maybe with a smaller font.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Mon, 05 May 2025 18:55:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>> Then, what about
>>
>> + (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
>> + #'warnings-suppress
>> + type
>> + "Click to suppress this warning type")
>
> May I suggest to look at how other applications handle such
> situations, i.e. when a message is shown and the user is given a
> capability of disabling it? Maybe that way we will find
> implementation ideas that are both familiar to users and look nicer?
Here is an interesting solution of using the context menu
to suppress warnings:
https://stackoverflow.com/questions/32085708/suppress-warnings-in-visual-studio-2015-for-custom-code-analyzers
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 06 May 2025 07:41:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 05 May 2025 21:53:31 +0300, Juri Linkov <juri <at> linkov.net> said:
>>> Then, what about
>>>
>>> + (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
>>> + #'warnings-suppress
>>> + type
>>> + "Click to suppress this warning type")
>>
>> May I suggest to look at how other applications handle such
>> situations, i.e. when a message is shown and the user is given a
>> capability of disabling it? Maybe that way we will find
>> implementation ideas that are both familiar to users and look nicer?
Juri> Here is an interesting solution of using the context menu
Juri> to suppress warnings:
Juri> https://stackoverflow.com/questions/32085708/suppress-warnings-in-visual-studio-2015-for-custom-code-analyzers
I conclude from that that we should use U+26A0 U+FE0F ⚠️ as the symbol
to insert. Right clicking does not necessarily come easy to Emacs
users, so I still think a text button is needed.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 06 May 2025 11:30:05 GMT)
Full text and
rfc822 format available.
Message #97 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Ihor Radchenko <yantar92 <at> posteo.net>,
> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com
> Date: Tue, 06 May 2025 09:39:56 +0200
>
> >>>>> On Mon, 05 May 2025 21:53:31 +0300, Juri Linkov <juri <at> linkov.net> said:
>
> >>> Then, what about
> >>>
> >>> + (insert (buttonize (concat (icon-string 'warnings-suppress) " [Suppress?]")
> >>> + #'warnings-suppress
> >>> + type
> >>> + "Click to suppress this warning type")
> >>
> >> May I suggest to look at how other applications handle such
> >> situations, i.e. when a message is shown and the user is given a
> >> capability of disabling it? Maybe that way we will find
> >> implementation ideas that are both familiar to users and look nicer?
>
> Juri> Here is an interesting solution of using the context menu
> Juri> to suppress warnings:
>
> Juri> https://stackoverflow.com/questions/32085708/suppress-warnings-in-visual-studio-2015-for-custom-code-analyzers
>
> I conclude from that that we should use U+26A0 U+FE0F ⚠️ as the symbol
> to insert.
Really? So we've just made another full circle back to the beginning?
Where someone said, and I agree, that showing ⚠️ explains itself worse
than the existing symbol, because it could be easily interpreted as
meaning just "Warning".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 06 May 2025 12:05:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 77917 <at> debbugs.gnu.org (full text, mbox):
On Tue, 06 May 2025 14:29:34 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, Ihor Radchenko <yantar92 <at> posteo.net>,
>> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com
>> Date: Tue, 06 May 2025 09:39:56 +0200
>>
>> >>>>> On Mon, 05 May 2025 21:53:31 +0300, Juri Linkov <juri <at> linkov.net> said:
>>
>> >>> Then, what about
>> >>>
>> >>> + (insert (buttonize (concat (icon-string 'warnings-suppress) "
>> >>> [Suppress?]")
>> >>> + #'warnings-suppress
>> >>> + type
>> >>> + "Click to suppress this warning type")
>> >>
>> >> May I suggest to look at how other applications handle such
>> >> situations, i.e. when a message is shown and the user is given a
>> >> capability of disabling it? Maybe that way we will find
>> >> implementation ideas that are both familiar to users and look nicer?
>>
>> Juri> Here is an interesting solution of using the context menu
>> Juri> to suppress warnings:
>>
>> Juri> https://stackoverflow.com/questions/32085708/suppress-warnings-in-visual-studio-2015-for-custom-code-analyzers
>>
>> I conclude from that that we should use U+26A0 U+FE0F ⚠️ as the symbol
>> to insert.
>
> Really? So we've just made another full circle back to the beginning?
> Where someone said, and I agree, that showing ⚠️ explains itself worse
> than the existing symbol, because it could be easily interpreted as
> meaning just "Warning".
What about the character "ℹ" (#x2139 INFORMATION SOURCE), perhaps with a
box face attribute, or alternatively as emoji "ℹ️"? This sign is widely
recognized and I think even invites clicking to see what the information
is (though having an explicit button as well would avoid any
misunderstanding).
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 06 May 2025 12:54:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 06 May 2025 14:29:34 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
Eli> Really? So we've just made another full circle back to the beginning?
Eli> Where someone said, and I agree, that showing ⚠️ explains itself worse
Eli> than the existing symbol, because it could be easily interpreted as
Eli> meaning just "Warning".
But ⛔ means "you have done something wrong", at least to some.
How about we just drop the icon completely?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 06 May 2025 15:35:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Robert Pluim <rpluim <at> gmail.com>, yantar92 <at> posteo.net,
> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com, juri <at> linkov.net
> Date: Tue, 06 May 2025 14:04:07 +0200
>
> On Tue, 06 May 2025 14:29:34 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> I conclude from that that we should use U+26A0 U+FE0F ⚠️ as the symbol
> >> to insert.
> >
> > Really? So we've just made another full circle back to the beginning?
> > Where someone said, and I agree, that showing ⚠️ explains itself worse
> > than the existing symbol, because it could be easily interpreted as
> > meaning just "Warning".
>
> What about the character "ℹ" (#x2139 INFORMATION SOURCE), perhaps with a
> box face attribute, or alternatively as emoji "ℹ️"? This sign is widely
> recognized and I think even invites clicking to see what the information
> is (though having an explicit button as well would avoid any
> misunderstanding).
If this is recognized widely enough, sure. But can you point to some
examples of using this for that purpose?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 06 May 2025 15:39:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: juri <at> linkov.net, yantar92 <at> posteo.net, 77917 <at> debbugs.gnu.org,
> prot <at> protesilaos.com
> Date: Tue, 06 May 2025 14:53:49 +0200
>
> >>>>> On Tue, 06 May 2025 14:29:34 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> Eli> Really? So we've just made another full circle back to the beginning?
> Eli> Where someone said, and I agree, that showing ⚠️ explains itself worse
> Eli> than the existing symbol, because it could be easily interpreted as
> Eli> meaning just "Warning".
>
> But ⛔ means "you have done something wrong", at least to some.
Which is why someone suggested to use ✖ or ❌.
> How about we just drop the icon completely?
And go for another circle? It was you who suggested to go back to am
icon, based on an example of a similar feature posted by Juri.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Tue, 06 May 2025 19:27:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 77917 <at> debbugs.gnu.org (full text, mbox):
On Tue, 06 May 2025 18:33:48 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Robert Pluim <rpluim <at> gmail.com>, yantar92 <at> posteo.net,
>> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com, juri <at> linkov.net
>> Date: Tue, 06 May 2025 14:04:07 +0200
>>
>> On Tue, 06 May 2025 14:29:34 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> >> I conclude from that that we should use U+26A0 U+FE0F ⚠️ as the symbol
>> >> to insert.
>> >
>> > Really? So we've just made another full circle back to the beginning?
>> > Where someone said, and I agree, that showing ⚠️ explains itself worse
>> > than the existing symbol, because it could be easily interpreted as
>> > meaning just "Warning".
>>
>> What about the character "ℹ" (#x2139 INFORMATION SOURCE), perhaps with a
>> box face attribute, or alternatively as emoji "ℹ️"? This sign is widely
>> recognized and I think even invites clicking to see what the information
>> is (though having an explicit button as well would avoid any
>> misunderstanding).
>
> If this is recognized widely enough, sure. But can you point to some
> examples of using this for that purpose?
If you mean an editor using "ℹ" or "ℹ️" as button to display otherwise
hidden information, then no, I don't know of any such editors (but I
have little acquaintance of editors besides Emacs :). I have seen "ℹ"
used simply to mark (but not reveal) an informative message; here is an
example of output in the R console:
https://r4ds.hadley.nz/intro.html#the-tidyverse
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Wed, 07 May 2025 07:14:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> I conclude from that that we should use U+26A0 U+FE0F ⚠️ as the symbol
> to insert. Right clicking does not necessarily come easy to Emacs
> users, so I still think a text button is needed.
Ok, based on the feedback from everyone here is the patch
that should satisfy all requirements:
diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 6c77d57a6ba..f3baa019ad2 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -216,7 +216,7 @@ warning-suppress-p
some-match))
(define-icon warnings-suppress button
- `((emoji "⛔")
+ `((emoji "⚠️")
;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
(symbol ,(if (and (eq system-type 'windows-nt)
(null window-system))
@@ -333,6 +333,14 @@ display-warning
(insert (format (nth 1 level-info)
(format warning-type-format typename))
message)
+ ;; Don't output the buttons when doing batch compilation
+ ;; and similar.
+ (unless (or noninteractive (eq type 'bytecomp))
+ (insert " " (buttonize (propertize
+ "[Suppress]" 'face
+ '(variable-pitch (:height 0.9)))
+ #'warnings-suppress type)
+ " "))
(funcall newline)
(when (and warning-fill-prefix
(not (string-search "\n" message))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Wed, 07 May 2025 07:26:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 06 May 2025 18:38:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: juri <at> linkov.net, yantar92 <at> posteo.net, 77917 <at> debbugs.gnu.org,
>> prot <at> protesilaos.com
>> Date: Tue, 06 May 2025 14:53:49 +0200
>>
>> >>>>> On Tue, 06 May 2025 14:29:34 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>>
Eli> Really? So we've just made another full circle back to the beginning?
Eli> Where someone said, and I agree, that showing ⚠️ explains itself worse
Eli> than the existing symbol, because it could be easily interpreted as
Eli> meaning just "Warning".
>>
>> But ⛔ means "you have done something wrong", at least to some.
Eli> Which is why someone suggested to use ✖ or ❌.
OK
>> How about we just drop the icon completely?
Eli> And go for another circle? It was you who suggested to go back to am
Eli> icon, based on an example of a similar feature posted by Juri.
OK, in that case we need the right icon, and a text button at the end
of the warning message.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Wed, 07 May 2025 07:36:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 07 May 2025 09:57:11 +0300, Juri Linkov <juri <at> linkov.net> said:
>> I conclude from that that we should use U+26A0 U+FE0F ⚠️ as the symbol
>> to insert. Right clicking does not necessarily come easy to Emacs
>> users, so I still think a text button is needed.
Juri> Ok, based on the feedback from everyone here is the patch
Juri> that should satisfy all requirements:
Juri> diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
Juri> index 6c77d57a6ba..f3baa019ad2 100644
Juri> --- a/lisp/emacs-lisp/warnings.el
Juri> +++ b/lisp/emacs-lisp/warnings.el
Juri> @@ -216,7 +216,7 @@ warning-suppress-p
Juri> some-match))
Juri>
Juri> (define-icon warnings-suppress button
Juri> - `((emoji "⛔")
Juri> + `((emoji "⚠️")
Juri> ;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
Juri> (symbol ,(if (and (eq system-type 'windows-nt)
Juri> (null window-system))
Juri> @@ -333,6 +333,14 @@ display-warning
Juri> (insert (format (nth 1 level-info)
Juri> (format warning-type-format typename))
Juri> message)
Juri> + ;; Don't output the buttons when doing batch compilation
Juri> + ;; and similar.
Juri> + (unless (or noninteractive (eq type 'bytecomp))
Juri> + (insert " " (buttonize (propertize
Juri> + "[Suppress]" 'face
Juri> + '(variable-pitch (:height 0.9)))
Juri> + #'warnings-suppress type)
Juri> + " "))
Juri> (funcall newline)
Juri> (when (and warning-fill-prefix
Juri> (not (string-search "\n" message))
I donʼt think we need the trailing space, but the rest looks good to
me. I donʼt mind if we end up preferring ❌, but ⛔ is right out.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Wed, 07 May 2025 16:20:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> I donʼt think we need the trailing space, but the rest looks good to
> me.
I tried without the trailing space, but then an underline is added
at the end. Very strange effect. Maybe a bug?
> I donʼt mind if we end up preferring ❌, but ⛔ is right out.
Everyone uses ⚠️ for warnings.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Wed, 07 May 2025 17:00:01 GMT)
Full text and
rfc822 format available.
Message #127 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 07 May 2025 19:16:46 +0300, Juri Linkov <juri <at> linkov.net> said:
>> I donʼt think we need the trailing space, but the rest looks good to
>> me.
Juri> I tried without the trailing space, but then an underline is added
Juri> at the end. Very strange effect. Maybe a bug?
Some interaction between the `button' or `link' face from the
`buttonize' with the :height spec?
>> I donʼt mind if we end up preferring ❌, but ⛔ is right out.
Juri> Everyone uses ⚠️ for warnings.
OK by me.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Wed, 07 May 2025 17:25:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> >> I donʼt think we need the trailing space, but the rest looks good to
> >> me.
>
> Juri> I tried without the trailing space, but then an underline is added
> Juri> at the end. Very strange effect. Maybe a bug?
>
> Some interaction between the `button' or `link' face from the
> `buttonize' with the :height spec?
Very interesting: 'display-warning' uses the function 'newline'
that basically does such a trick:
(let ((last-command-event ?\n))
(self-insert-command 1))
But the problem is that 'self-insert-command' inherits
the button text properties to the newline. And with
these text properties the newline is displayed as
an underlined space character.
I don't know the reason why 'display-warning' uses 'newline',
but after replacing 'newline' with a plain "\n"
it is displayed correctly:
diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 6c77d57a6ba..9714abea213 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -216,7 +216,7 @@ warning-suppress-p
some-match))
(define-icon warnings-suppress button
- `((emoji "⛔")
+ `((emoji "⚠️")
;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
(symbol ,(if (and (eq system-type 'windows-nt)
(null window-system))
@@ -333,7 +333,14 @@ display-warning
(insert (format (nth 1 level-info)
(format warning-type-format typename))
message)
- (funcall newline)
+ ;; Don't output the buttons when doing batch compilation
+ ;; and similar.
+ (unless (or noninteractive (eq type 'bytecomp))
+ (insert " " (buttonize (propertize
+ "[Suppress]" 'face
+ '(variable-pitch (:height 0.9)))
+ #'warnings-suppress type)
+ "\n"))
(when (and warning-fill-prefix
(not (string-search "\n" message))
(not noninteractive))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 05:11:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> On May 7, 2025, at 10:22 AM, Juri Linkov <juri <at> linkov.net> wrote:
>
>>>> I donʼt think we need the trailing space, but the rest looks good to
>>>> me.
>>
>> Juri> I tried without the trailing space, but then an underline is added
>> Juri> at the end. Very strange effect. Maybe a bug?
>>
>> Some interaction between the `button' or `link' face from the
>> `buttonize' with the :height spec?
>
> Very interesting: 'display-warning' uses the function 'newline'
> that basically does such a trick:
>
> (let ((last-command-event ?\n))
> (self-insert-command 1))
>
> But the problem is that 'self-insert-command' inherits
> the button text properties to the newline. And with
> these text properties the newline is displayed as
> an underlined space character.
>
> I don't know the reason why 'display-warning' uses 'newline',
> but after replacing 'newline' with a plain "\n"
> it is displayed correctly:
>
> diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
> index 6c77d57a6ba..9714abea213 100644
> --- a/lisp/emacs-lisp/warnings.el
> +++ b/lisp/emacs-lisp/warnings.el
> @@ -216,7 +216,7 @@ warning-suppress-p
> some-match))
>
> (define-icon warnings-suppress button
> - `((emoji "⛔")
> + `((emoji "⚠️")
> ;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
> (symbol ,(if (and (eq system-type 'windows-nt)
> (null window-system))
> @@ -333,7 +333,14 @@ display-warning
> (insert (format (nth 1 level-info)
> (format warning-type-format typename))
> message)
> - (funcall newline)
> + ;; Don't output the buttons when doing batch compilation
> + ;; and similar.
> + (unless (or noninteractive (eq type 'bytecomp))
> + (insert " " (buttonize (propertize
> + "[Suppress]" 'face
> + '(variable-pitch (:height 0.9)))
> + #'warnings-suppress type)
> + "\n"))
> (when (and warning-fill-prefix
> (not (string-search "\n" message))
> (not noninteractive))
Using ⚠️ to mean “suppress” feels wrong. Maybe just display the ⚠️ or ⛔ in front of the warning, and append the suppress button at the end of the message? (But doesn’t the warning buffer only display warning?)
Also can we replace the ■ symbol with ⊖ or ⛒? The ■ symbol is very confusing.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 05:16:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> On May 7, 2025, at 10:10 PM, Yuan Fu <casouri <at> gmail.com> wrote:
>
>
>
>> On May 7, 2025, at 10:22 AM, Juri Linkov <juri <at> linkov.net> wrote:
>>
>>>>> I donʼt think we need the trailing space, but the rest looks good to
>>>>> me.
>>>
>>> Juri> I tried without the trailing space, but then an underline is added
>>> Juri> at the end. Very strange effect. Maybe a bug?
>>>
>>> Some interaction between the `button' or `link' face from the
>>> `buttonize' with the :height spec?
>>
>> Very interesting: 'display-warning' uses the function 'newline'
>> that basically does such a trick:
>>
>> (let ((last-command-event ?\n))
>> (self-insert-command 1))
>>
>> But the problem is that 'self-insert-command' inherits
>> the button text properties to the newline. And with
>> these text properties the newline is displayed as
>> an underlined space character.
>>
>> I don't know the reason why 'display-warning' uses 'newline',
>> but after replacing 'newline' with a plain "\n"
>> it is displayed correctly:
>>
>> diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
>> index 6c77d57a6ba..9714abea213 100644
>> --- a/lisp/emacs-lisp/warnings.el
>> +++ b/lisp/emacs-lisp/warnings.el
>> @@ -216,7 +216,7 @@ warning-suppress-p
>> some-match))
>>
>> (define-icon warnings-suppress button
>> - `((emoji "⛔")
>> + `((emoji "⚠️")
>> ;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
>> (symbol ,(if (and (eq system-type 'windows-nt)
>> (null window-system))
>> @@ -333,7 +333,14 @@ display-warning
>> (insert (format (nth 1 level-info)
>> (format warning-type-format typename))
>> message)
>> - (funcall newline)
>> + ;; Don't output the buttons when doing batch compilation
>> + ;; and similar.
>> + (unless (or noninteractive (eq type 'bytecomp))
>> + (insert " " (buttonize (propertize
>> + "[Suppress]" 'face
>> + '(variable-pitch (:height 0.9)))
>> + #'warnings-suppress type)
>> + "\n"))
>> (when (and warning-fill-prefix
>> (not (string-search "\n" message))
>> (not noninteractive))
>
> Using ⚠️ to mean “suppress” feels wrong. Maybe just display the ⚠️ or ⛔ in front of the warning, and append the suppress button at the end of the message? (But doesn’t the warning buffer only display warning?)
Re-reading your patch, I realized your patch does exactly what I described. Maybe we should rename the icon so it doesn’t say suppress.
And for the symbol we could use ⚠.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 06:53:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 77917 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> (define-icon warnings-suppress button
>>> - `((emoji "⛔")
>>> + `((emoji "⚠️")
> [...]
> Re-reading your patch, I realized your patch does exactly what
> I described. Maybe we should rename the icon so it doesn’t say
> suppress.
Unfortunately, renaming an icon is not so simple.
First we need to mark an old name as obsolete
because very likely many users already customized it
with 'M-x customize-icon RET warnings-suppress RET'
that adds to the custom file a setting like this:
(custom-set-icons
'(warnings-suppress ((emoji "⚠️") (symbol " ■ ") (text " stop "))))
And I even don't know how to make it obsolete.
For example, there is 'define-obsolete-face-alias',
but no something like 'define-obsolete-icon-alias'.
> And for the symbol we could use ⚠.
Thanks. I tried to find a suitable character for the symbol,
but didn't realize this could be used for it.
Here is the patch that also updates the docstring:
[warnings-suppress.patch (text/x-diff, inline)]
diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 6c77d57a6ba..54a35fee3a9 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -216,15 +216,15 @@ warning-suppress-p
some-match))
(define-icon warnings-suppress button
- `((emoji "⛔")
- ;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
+ `((emoji "⚠️")
+ ;; Many MS-Windows console fonts don't have good glyphs for symbols.
(symbol ,(if (and (eq system-type 'windows-nt)
(null window-system))
" » "
- " ■ "))
- (text " stop "))
- "Suppress warnings."
- :version "29.1"
+ " ⚠ "))
+ (text " warning "))
+ "Indicate and optionally suppress warnings."
+ :version "31.1"
:help-echo "Click to suppress this warning type")
(defun warnings-suppress (type)
@@ -333,7 +333,16 @@ display-warning
(insert (format (nth 1 level-info)
(format warning-type-format typename))
message)
- (funcall newline)
+ ;; Don't output the buttons when doing batch compilation
+ ;; and similar.
+ (unless (or noninteractive (eq type 'bytecomp))
+ (insert " " (buttonize (propertize
+ "[Suppress]" 'face
+ '(variable-pitch (:height 0.9)))
+ #'warnings-suppress type)
+ "\n"))
+ (unless (bolp)
+ (funcall newline))
(when (and warning-fill-prefix
(not (string-search "\n" message))
(not noninteractive))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 07:29:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Robert Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
> 77917 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>,
> prot <at> protesilaos.com
> Date: Thu, 08 May 2025 09:45:38 +0300
>
> (define-icon warnings-suppress button
> - `((emoji "⛔")
> - ;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
> + `((emoji "⚠️")
> + ;; Many MS-Windows console fonts don't have good glyphs for symbols.
> (symbol ,(if (and (eq system-type 'windows-nt)
> (null window-system))
> " » "
> - " ■ "))
> - (text " stop "))
> - "Suppress warnings."
> - :version "29.1"
> + " ⚠ "))
> + (text " warning "))
Since the 'symbol' value was changed to express "warning" rather than
"suppress", the symbol used for terminals on MS-Windows needs to be
also modified, since the previous one has nothing in common with
"warning".
Also, are you sure that show U+26A0 ⚠ is a good idea for the 'symbol'
preference? At least on TTY frames, that character has problems
because its glyph is wide, and many terminal emulators have trouble
showing it in an Emacs window.
So I think the 'symbol' alternative still needs work.
Btw, since this icon is called "warning-suppress", did anyone think
about showing a cross or a strike-through over the icon/symbol?
Because using ⚠ as "warning-suppress" is at least strange, IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 17:24:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>> (define-icon warnings-suppress button
>> - `((emoji "⛔")
>> - ;; Many MS-Windows console fonts don't have good glyphs for U+25A0.
>> + `((emoji "⚠️")
>> + ;; Many MS-Windows console fonts don't have good glyphs for symbols.
>> (symbol ,(if (and (eq system-type 'windows-nt)
>> (null window-system))
>> " » "
>> - " ■ "))
>> - (text " stop "))
>> - "Suppress warnings."
>> - :version "29.1"
>> + " ⚠ "))
>> + (text " warning "))
>
> Since the 'symbol' value was changed to express "warning" rather than
> "suppress", the symbol used for terminals on MS-Windows needs to be
> also modified, since the previous one has nothing in common with
> "warning".
⚠️ contains an exclamation mark, so the symbol could be just '!' or '!!'
like in flymake's margin/fringe.
> Also, are you sure that show U+26A0 ⚠ is a good idea for the 'symbol'
> preference? At least on TTY frames, that character has problems
> because its glyph is wide, and many terminal emulators have trouble
> showing it in an Emacs window.
I tried ⚠ on a tty, and it looks very poor, barely recognizable.
So need to find a new symbol.
> Btw, since this icon is called "warning-suppress", did anyone think
> about showing a cross or a strike-through over the icon/symbol?
> Because using ⚠ as "warning-suppress" is at least strange, IMO.
Since the general preference is to have the [Suppress] link at the end,
we need to use a new name "warning" for the icon.
Therefore I retract my patch in favor of Kévin's patch from
https://debbugs.gnu.org/61413#108 that added the new icon "warning"
with a nice svg image. When installed, it should be tweaked
for further improvements (including FIXME).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 17:31:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>> Also, are you sure that show U+26A0 ⚠ is a good idea for the 'symbol'
>> preference? At least on TTY frames, that character has problems
>> because its glyph is wide, and many terminal emulators have trouble
>> showing it in an Emacs window.
>
> I tried ⚠ on a tty, and it looks very poor, barely recognizable.
> So need to find a new symbol.
▲ looks more solid on a tty.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 18:54:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Tue, 06 May 2025 18:38:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Robert Pluim <rpluim <at> gmail.com>
> >> Cc: juri <at> linkov.net, yantar92 <at> posteo.net, 77917 <at> debbugs.gnu.org,
> >> prot <at> protesilaos.com
> >> Date: Tue, 06 May 2025 14:53:49 +0200
> >>
> >> >>>>> On Tue, 06 May 2025 14:29:34 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> >>
> Eli> Really? So we've just made another full circle back to the beginning?
> Eli> Where someone said, and I agree, that showing ⚠️ explains itself worse
> Eli> than the existing symbol, because it could be easily interpreted as
> Eli> meaning just "Warning".
> >>
> >> But ⛔ means "you have done something wrong", at least to some.
>
> Eli> Which is why someone suggested to use ✖ or ❌.
>
> OK
>
> >> How about we just drop the icon completely?
>
> Eli> And go for another circle? It was you who suggested to go back to am
> Eli> icon, based on an example of a similar feature posted by Juri.
>
> OK, in that case we need the right icon, and a text button at the end
> of the warning message.
In case that can help, I think this is more or less what this patch on
bug#61413 does: (with screenshot)
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
Direct link to the patch:
<https://debbugs.gnu.org/cgi/bugreport.cgi?filename=0001-Use-plain-text-for-warning-supression-button.patch;bug=61413;msg=108;att=1>
Screenshot:
<https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=108;bug=61413;filename=Screenshot_20250223_163540.png>
Similar to Juri's latest patch; in short,
* stop using the "warnings-suppress" icon; keep it for
backward-compatibility in case there are out-of-tree users,
* insert a new plain "warning" icon (with SVG representation that can
use the 'warning face),
* add a text button for suppression.
(The main feedback on that patch, IIRC, was that the 'button face looks
too much like a link instead of something like 'custom-button. Wasn't
sure where to go from there so dropped the ball after that; thank y'all
for picking it back up here)
(There was also a FIXME for a problem that Juri solved in the other
subthread by just inserting "\n" instead of calling 'newline, AFAIU)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 19:11:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: casouri <at> gmail.com, 77917 <at> debbugs.gnu.org, rpluim <at> gmail.com,
> prot <at> protesilaos.com, yantar92 <at> posteo.net
> Date: Thu, 08 May 2025 20:29:35 +0300
>
> >> Also, are you sure that show U+26A0 ⚠ is a good idea for the 'symbol'
> >> preference? At least on TTY frames, that character has problems
> >> because its glyph is wide, and many terminal emulators have trouble
> >> showing it in an Emacs window.
> >
> > I tried ⚠ on a tty, and it looks very poor, barely recognizable.
> > So need to find a new symbol.
>
> ▲ looks more solid on a tty.
But will it be perceived as a warning sign? It looks just a triangle.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Thu, 08 May 2025 19:16:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, yantar92 <at> posteo.net,
> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com, juri <at> linkov.net
> Date: Thu, 08 May 2025 20:53:17 +0200
>
> In case that can help, I think this is more or less what this patch on
> bug#61413 does: (with screenshot)
>
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
>
> Direct link to the patch:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?filename=0001-Use-plain-text-for-warning-supression-button.patch;bug=61413;msg=108;att=1>
>
> Screenshot:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=108;bug=61413;filename=Screenshot_20250223_163540.png>
>
> Similar to Juri's latest patch; in short,
>
> * stop using the "warnings-suppress" icon; keep it for
> backward-compatibility in case there are out-of-tree users,
> * insert a new plain "warning" icon (with SVG representation that can
> use the 'warning face),
> * add a text button for suppression.
How about doing that, but without the icon? The icon is problematic
on TTY frames, and why do we need it, when the text already says
"Warning: SOMETHING"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Fri, 09 May 2025 02:30:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> On May 8, 2025, at 12:10 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: casouri <at> gmail.com, 77917 <at> debbugs.gnu.org, rpluim <at> gmail.com,
>> prot <at> protesilaos.com, yantar92 <at> posteo.net
>> Date: Thu, 08 May 2025 20:29:35 +0300
>>
>>>> Also, are you sure that show U+26A0 ⚠ is a good idea for the 'symbol'
>>>> preference? At least on TTY frames, that character has problems
>>>> because its glyph is wide, and many terminal emulators have trouble
>>>> showing it in an Emacs window.
>>>
>>> I tried ⚠ on a tty, and it looks very poor, barely recognizable.
>>> So need to find a new symbol.
>>
>> ▲ looks more solid on a tty.
>
> But will it be perceived as a warning sign? It looks just a triangle.
My two cents, and feel free to ignore: maybe just use the exclamation mark. We don’t have to use a “unicode” symbol for the symbol category. “!” conveys the idea and is well supported.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Fri, 09 May 2025 02:50:01 GMT)
Full text and
rfc822 format available.
Message #163 received at submit <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Robert Pluim <rpluim <at> gmail.com> writes:
>
>>>>>>> On Tue, 06 May 2025 18:38:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>>
>> >> From: Robert Pluim <rpluim <at> gmail.com>
>> >> Cc: juri <at> linkov.net, yantar92 <at> posteo.net, 77917 <at> debbugs.gnu.org,
>> >> prot <at> protesilaos.com
>> >> Date: Tue, 06 May 2025 14:53:49 +0200
>> >>
>> >> >>>>> On Tue, 06 May 2025 14:29:34 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> >>
>> Eli> Really? So we've just made another full circle back to the beginning?
>> Eli> Where someone said, and I agree, that showing ⚠️ explains itself worse
>> Eli> than the existing symbol, because it could be easily interpreted as
>> Eli> meaning just "Warning".
>> >>
>> >> But ⛔ means "you have done something wrong", at least to some.
>>
>> Eli> Which is why someone suggested to use ✖ or ❌.
>>
>> OK
>>
>> >> How about we just drop the icon completely?
>>
>> Eli> And go for another circle? It was you who suggested to go back to am
>> Eli> icon, based on an example of a similar feature posted by Juri.
>>
>> OK, in that case we need the right icon, and a text button at the end
>> of the warning message.
>
> In case that can help, I think this is more or less what this patch on
> bug#61413 does: (with screenshot)
>
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
>
> Direct link to the patch:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?filename=0001-Use-plain-text-for-warning-supression-button.patch;bug=61413;msg=108;att=1>
>
> Screenshot:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=108;bug=61413;filename=Screenshot_20250223_163540.png>
>
> Similar to Juri's latest patch; in short,
>
> * stop using the "warnings-suppress" icon; keep it for
> backward-compatibility in case there are out-of-tree users,
> * insert a new plain "warning" icon (with SVG representation that can
> use the 'warning face),
> * add a text button for suppression.
>
> (The main feedback on that patch, IIRC, was that the 'button face looks
> too much like a link instead of something like 'custom-button. Wasn't
> sure where to go from there so dropped the ball after that; thank y'all
> for picking it back up here)
>
> (There was also a FIXME for a problem that Juri solved in the other
> subthread by just inserting "\n" instead of calling 'newline, AFAIU)
I'm not sure I'm following all of this, but FWIW, I like ⚠️
as an icon merely to indicate a warning; and while I'm fine
with the text "suppress" as a button, maybe 🤫 would work as an
icon button to mean silence this (aka suppress).
--
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Fri, 09 May 2025 06:30:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>>>>> Also, are you sure that show U+26A0 ⚠ is a good idea for the 'symbol'
>>>>> preference? At least on TTY frames, that character has problems
>>>>> because its glyph is wide, and many terminal emulators have trouble
>>>>> showing it in an Emacs window.
>>>>
>>>> I tried ⚠ on a tty, and it looks very poor, barely recognizable.
>>>> So need to find a new symbol.
>>>
>>> ▲ looks more solid on a tty.
>>
>> But will it be perceived as a warning sign? It looks just a triangle.
>
> My two cents, and feel free to ignore: maybe just use the exclamation
> mark. We don’t have to use a “unicode” symbol for the symbol
> category. “!” conveys the idea and is well supported.
“!” is fine, like in flymake-margin-indicators-string.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Fri, 09 May 2025 06:31:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>> * stop using the "warnings-suppress" icon; keep it for
>> backward-compatibility in case there are out-of-tree users,
>> * insert a new plain "warning" icon (with SVG representation that can
>> use the 'warning face),
>> * add a text button for suppression.
>
> How about doing that, but without the icon?
The icon helps to draw the user's attention to the warning.
Other IDEs do this, e.g. https://i.sstatic.net/gppvo.jpg
> The icon is problematic on TTY frames, and why do we need it, when the
> text already says "Warning: SOMETHING"?
This is not problematic since 'define-icon' supports many layers.
From (info "(elisp) Icons"):
If ‘icon-preference’ is ‘(image emoji symbol text)’ (i.e., allowing all of
these forms of icons), in this case, ‘icon-string’ will first check that
Emacs is able to display images at all, and then whether it has support
for each of those different image formats. If that fails, Emacs will
check whether Emacs can display emojis (in the current frame). If that
fails, it'll check whether it can display the symbol in question. If
that fails, it'll use the plain text version.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Fri, 09 May 2025 06:55:01 GMT)
Full text and
rfc822 format available.
Message #172 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>,
> rpluim <at> gmail.com,
> yantar92 <at> posteo.net, 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com
> Date: Fri, 09 May 2025 09:25:50 +0300
>
> >> * stop using the "warnings-suppress" icon; keep it for
> >> backward-compatibility in case there are out-of-tree users,
> >> * insert a new plain "warning" icon (with SVG representation that can
> >> use the 'warning face),
> >> * add a text button for suppression.
> >
> > How about doing that, but without the icon?
>
> The icon helps to draw the user's attention to the warning.
We have other, more portable ways of drawing attention. For example,
use the 'warning' face, or show "!! WARNING !!" instead, or both.
> > The icon is problematic on TTY frames, and why do we need it, when the
> > text already says "Warning: SOMETHING"?
>
> This is not problematic since 'define-icon' supports many layers.
> >From (info "(elisp) Icons"):
>
> If ‘icon-preference’ is ‘(image emoji symbol text)’ (i.e., allowing all of
> these forms of icons), in this case, ‘icon-string’ will first check that
> Emacs is able to display images at all, and then whether it has support
> for each of those different image formats. If that fails, Emacs will
> check whether Emacs can display emojis (in the current frame). If that
> fails, it'll check whether it can display the symbol in question. If
> that fails, it'll use the plain text version.
Our current facilities for determining whether a particular expression
of an icon can be displayed by the frame are somewhat limited. For
example, char-displayable-p could return non-nil on a GUI frame even
if there's no font that can display a character, and on a TTY frame we
think any character can be displayed if the terminal's encoding is
UTF-8. That's the reason for the delicate dance with default values
for the 'symbol' choice we have now.
Dropping the icon solves all those problems entirely, and without any
leftovers.
I understand the urge to use the icons, since when it works, the
display is much nicer. But IMNSHO, the icon machinery we have is not
yet mature enough to use it in such ubiquitous situations, where
user-facing messages need to explain themselves with 110% clarity.
Showing something like "\u25b2Warning: ..." is not my idea of a good
warning UX. We should try avoiding this at all costs, even if that
means, sadly, dropping the icon.
Or maybe we could come up with something that uses the icon only on
GUI frames. But even then, we should modify icons.el to use
char-displayable-on-frame-p instead, to avoid false positives.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Fri, 09 May 2025 07:37:02 GMT)
Full text and
rfc822 format available.
Message #175 received at 77917 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, yantar92 <at> posteo.net,
>> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com, juri <at> linkov.net
>> Date: Thu, 08 May 2025 20:53:17 +0200
>>
>> In case that can help, I think this is more or less what this patch on
>> bug#61413 does: (with screenshot)
>>
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
>>
>> Direct link to the patch:
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?filename=0001-Use-plain-text-for-warning-supression-button.patch;bug=61413;msg=108;att=1>
>>
>> Screenshot:
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=108;bug=61413;filename=Screenshot_20250223_163540.png>
>>
>> Similar to Juri's latest patch; in short,
>>
>> * stop using the "warnings-suppress" icon; keep it for
>> backward-compatibility in case there are out-of-tree users,
>> * insert a new plain "warning" icon (with SVG representation that can
>> use the 'warning face),
>> * add a text button for suppression.
>
> How about doing that, but without the icon? The icon is problematic
> on TTY frames, and why do we need it, when the text already says
> "Warning: SOMETHING"?
No strong opinions myself¹. I don't think we ever _need_ icons anyway,
but I do find they can² be more immediately recognizable than prose; so
worth keeping IMO barring insurmountable technical problems?
So to your point about TTY frames, considering this definition…
(define-icon warning nil
'((image "warning.svg" "warning.pbm" :face warning)
(emoji "⚠️")
(symbol "⚠" :face warning)
(text "WARNING" :face warning))
"Warning indicator."
:version "31.1")
… and yesterday's observation that ⚠ is ill-suited in TTY frames, we
could drop the 'symbol representation altogether? Since we have
precedents for icons using "ASCII art" for the 'text representation³,
maybe…
(define-icon warning nil
'((image "warning.svg" "warning.pbm" :face warning)
(emoji "⚠️")
(text "/!\" :face warning))
"Warning indicator."
:version "31.1")
… would work well enough?⁴
¹ Sent my message yesterday after seeing Juri's patches converging
toward bug#61413#108, and figuring it'd be interesting to compare the
finer details - I only just now realize Juri had already linked to it in
bug#77917#145; sorry for the noise! Would have refrained from
commenting otherwise, since I feel like I have not been much help in
finding a satisfactory solution.
² Emphasis on "can", given the root cause for these reports ⛔
³ read-passwd--*-password-icon, outline-*-in-margins.
⁴ OT1H it addresses one nit I had with bug#61413#108, i.e. the text
presentation looking redundant with the string from warning-levels.
OTOH I don't know if we want to encourage ASCII art for 'text
representations, which could be better used as "accessible"
self-describing prose when visual imagery is not appropriate?
But then not sure how to square the "have-an-icon + accessible-text +
not-redundant-with-'warning-levels'-string" circle, at which point the
options I see are (a) indeed, drop the icon (b) re-think warning-levels
to accommodate icons, at which point see ¹ 🤐
(Maybe "icon 'text representations should be accessible prose" is a
false premise; e.g. that's what 'help-echo is for?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 11 May 2025 07:12:01 GMT)
Full text and
rfc822 format available.
Message #178 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> Since we have precedents for icons using "ASCII art" for the 'text
> representation³, maybe…
>
> (define-icon warning nil
> '((image "warning.svg" "warning.pbm" :face warning)
> (emoji "⚠️")
> (text "/!\" :face warning))
I remember trying to use ASCII art for the text representation but
then Lars noted it's intended to be used with a screen reader
by the visually impaired, etc. But it should be fine to
add ASCII art in the 'symbol' part of the icon definition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 11 May 2025 07:12:02 GMT)
Full text and
rfc822 format available.
Message #181 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> I understand the urge to use the icons, since when it works, the
> display is much nicer. But IMNSHO, the icon machinery we have is not
> yet mature enough to use it in such ubiquitous situations, where
> user-facing messages need to explain themselves with 110% clarity.
> Showing something like "\u25b2Warning: ..." is not my idea of a good
> warning UX. We should try avoiding this at all costs, even if that
> means, sadly, dropping the icon.
'define-icon' was used successfully in many other packages
for several releases without problems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 11 May 2025 07:40:04 GMT)
Full text and
rfc822 format available.
Message #184 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: kevin.legouguec <at> gmail.com, rpluim <at> gmail.com, yantar92 <at> posteo.net,
> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com
> Date: Sun, 11 May 2025 09:58:30 +0300
>
> > I understand the urge to use the icons, since when it works, the
> > display is much nicer. But IMNSHO, the icon machinery we have is not
> > yet mature enough to use it in such ubiquitous situations, where
> > user-facing messages need to explain themselves with 110% clarity.
> > Showing something like "\u25b2Warning: ..." is not my idea of a good
> > warning UX. We should try avoiding this at all costs, even if that
> > means, sadly, dropping the icon.
>
> 'define-icon' was used successfully in many other packages
> for several releases without problems.
It depend on the use. In this case, we use it for displaying
warnings, some of them are quite common on top of that. It is not a
coincidence that this particular use caused so many discussions and
bug reports.
I mentioned at least one problematic aspect of define-icon's usage.
Showing successful uses of it doesn't solve that problem in any way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 11 May 2025 16:54:07 GMT)
Full text and
rfc822 format available.
Message #187 received at 77917 <at> debbugs.gnu.org (full text, mbox):
>> > I understand the urge to use the icons, since when it works, the
>> > display is much nicer. But IMNSHO, the icon machinery we have is not
>> > yet mature enough to use it in such ubiquitous situations, where
>> > user-facing messages need to explain themselves with 110% clarity.
>> > Showing something like "\u25b2Warning: ..." is not my idea of a good
>> > warning UX. We should try avoiding this at all costs, even if that
>> > means, sadly, dropping the icon.
>>
>> 'define-icon' was used successfully in many other packages
>> for several releases without problems.
>
> It depend on the use. In this case, we use it for displaying
> warnings, some of them are quite common on top of that. It is not a
> coincidence that this particular use caused so many discussions and
> bug reports.
>
> I mentioned at least one problematic aspect of define-icon's usage.
> Showing successful uses of it doesn't solve that problem in any way.
If icons.el is broken, it should be fixed
because it's used by many packages.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77917; Package
emacs.
(Sun, 11 May 2025 19:25:02 GMT)
Full text and
rfc822 format available.
Message #190 received at 77917 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: kevin.legouguec <at> gmail.com, rpluim <at> gmail.com, yantar92 <at> posteo.net,
> 77917 <at> debbugs.gnu.org, prot <at> protesilaos.com
> Date: Sun, 11 May 2025 19:53:05 +0300
>
> >> > I understand the urge to use the icons, since when it works, the
> >> > display is much nicer. But IMNSHO, the icon machinery we have is not
> >> > yet mature enough to use it in such ubiquitous situations, where
> >> > user-facing messages need to explain themselves with 110% clarity.
> >> > Showing something like "\u25b2Warning: ..." is not my idea of a good
> >> > warning UX. We should try avoiding this at all costs, even if that
> >> > means, sadly, dropping the icon.
> >>
> >> 'define-icon' was used successfully in many other packages
> >> for several releases without problems.
> >
> > It depend on the use. In this case, we use it for displaying
> > warnings, some of them are quite common on top of that. It is not a
> > coincidence that this particular use caused so many discussions and
> > bug reports.
> >
> > I mentioned at least one problematic aspect of define-icon's usage.
> > Showing successful uses of it doesn't solve that problem in any way.
>
> If icons.el is broken, it should be fixed
> because it's used by many packages.
Agreed.
But selection of the symbols and the characters is still per each use
of icons.el. So some manual work is still needed in each case. In
particular, messages that are expected to be shown frequently should
use symbols and characters that can be displayed in most if not all
of the supported configurations and platforms.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 09 Jun 2025 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.