bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

Stop-sign emoji is confusing in context of warnings, because it
typically has red color, and looks like there was some error. Let's use
instead a "warning" emoji, which is typically shown in yellow color and
doesn't look as if immediate attention is needed.

* lisp/emacs-lisp/warnings.el (warnings-suppress): replace stop-sign emoji
with a warning emoji.
---
 lisp/emacs-lisp/warnings.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 31b840d6c83..3f18ed89808 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -204,7 +204,7 @@ warning-suppress-p
     some-match))
 \f
 (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))
-- 
2.39.0

bug#61413: Acknowledgement ([PATCH] Make warnings show a "warning" emoji instead of a stop-sign)

[Konstantin Kharlamov]

While at it, may I suggest to backport it to stable? Because we have native compilation in stable which causes *a lot* of these warnings, and having a less dramatic emoji for them would seem like a better user experience.

bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Eli Zaretskii]

merge 61413 60854
thanks

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Date: Sat, 11 Feb 2023 11:45:59 +0300
> 
> Stop-sign emoji is confusing in context of warnings, because it
> typically has red color, and looks like there was some error. Let's use
> instead a "warning" emoji, which is typically shown in yellow color and
> doesn't look as if immediate attention is needed.

This is a duplicate of bug#60854: you are misinterpreting the purpose
of the Emoji here.

bug#60854: bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

Jim Porter wrote:
> On 1/17/2023 2:19 PM, Kévin Le Gouguec wrote:
> > Jim Porter <jporterbugs <at> gmail.com> writes:
> >> Perhaps a bit better would be 🚫, whose official name is apparently "No Entry
> >> Sign", even though the slashed circle visual usually just means "No ____",
> >> e.g. "No Smoking". Hence, some sources call it the Prohibited emoji.
> >
> > (My ¢2: wouldn't a cross mark (❌) also work to convey the idea of
> > "suppressing" something?)
>
> That would work too. I still like turning this into a toggle button
> where the icon shows the current state (i.e. is it an active warning -
> ⚠️ - or has it been suppressed - ⚬). But changing to 🚫 or ❌ would be
> single-character patches, which is nice too.

As a user, seeing any of ❌ or 🚫 in compilation buffer I think immediately of a
problem because these emojis are shown in red color. You might say that color
depends on a font, however they both are even documented on emojipedia to be
"red", so rest assured, if there's a colorful emoji support on a user system,
most likely the color will be red.

The fact it's actually a button that is supposed to do something is an
interesting one, but since a button isn't actually used for displaying the
button, it's kind of an easter egg. We know it's a button, but no one else
will. (as a side note, I am also not sure why to make a button on every warning)

So please, let's either replace it with ⚠ as originally suggested, or make it an
actual button with an actual text "suppress warnings". As it stands now, just
replacing it with ❌ or 🚫 will not reduce any confusion.

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

On Sat, 2023-02-11 at 13:56 +0300, Konstantin Kharlamov wrote:
> Jim Porter wrote:
> > On 1/17/2023 2:19 PM, Kévin Le Gouguec wrote:
> > > Jim Porter <jporterbugs <at> gmail.com> writes:
> > > > Perhaps a bit better would be 🚫, whose official name is apparently "No
> > > > Entry
> > > > Sign", even though the slashed circle visual usually just means "No
> > > > ____",
> > > > e.g. "No Smoking". Hence, some sources call it the Prohibited emoji.
> > > 
> > > (My ¢2: wouldn't a cross mark (❌) also work to convey the idea of
> > > "suppressing" something?)
> > 
> > That would work too. I still like turning this into a toggle button
> > where the icon shows the current state (i.e. is it an active warning -
> > ⚠️ - or has it been suppressed - ⚬). But changing to 🚫 or ❌ would be
> > single-character patches, which is nice too.
> 
> As a user, seeing any of ❌ or 🚫 in compilation buffer I think immediately of
> a
> problem because these emojis are shown in red color. You might say that color
> depends on a font, however they both are even documented on emojipedia to be
> "red", so rest assured, if there's a colorful emoji support on a user system,
> most likely the color will be red.
> 
> The fact it's actually a button that is supposed to do something is an
> interesting one, but since a button isn't actually used for displaying the
> button, it's kind of an easter egg. We know it's a button, but no one else
> will. (as a side note, I am also not sure why to make a button on every
> warning)
> 
> So please, let's either replace it with ⚠ as originally suggested, or make it
> an
> actual button with an actual text "suppress warnings". As it stands now, just
> replacing it with ❌ or 🚫 will not reduce any confusion.

Given release is pretty close, how about at least replacing the emoji to radio
button? 🔘 This way it would be clearly a button, and also wouldn't have any
reds in it

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Thu, 30 Mar 2023 23:58:06 +0300
> 
> Given release is pretty close, how about at least replacing the emoji to radio
> button? 🔘 This way it would be clearly a button, and also wouldn't have any
> reds in it

Who says this character is widespread enough for us to use it?

Anyway, I see no reason to rush with this.  The current situation is
not really that bad, considering that these messages should not be
shown too frequently.  Feel free to suggest customizable changes for
master, and let's see where that leads us.  (IME, these fancy
characters are still not supported widely enough, but that's me.)

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

On Fri, 2023-03-31 at 08:55 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Date: Thu, 30 Mar 2023 23:58:06 +0300
> > 
> > Given release is pretty close, how about at least replacing the emoji to
> > radio
> > button? 🔘 This way it would be clearly a button, and also wouldn't have any
> > reds in it
> 
> Who says this character is widespread enough for us to use it?

🔘 was approved to Unicode in 2010¹. In comparison, the ⛔ character being used
now was approved in 2009². Also, both characters were part of the same release
Emoji Version 1.0.

So I guess, there shouldn't be much difference?

> Anyway, I see no reason to rush with this.  The current situation is
> not really that bad, considering that these messages should not be
> shown too frequently.

My experience is the opposite, which is why I'm pinging this issue. When native
compilation is enabled (which is guess is what we'd prefer to see as it improves
performance for our users), it is shown every time stuff from ELPA gets byte-
recompiled. That is, every time you install or update packages, you will get
some warnings.

1: https://emojipedia.org/radio-button/
2: https://emojipedia.org/no-entry/

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

On Fri, 2023-03-31 at 09:19 +0300, Konstantin Kharlamov wrote:
> On Fri, 2023-03-31 at 08:55 +0300, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > Date: Thu, 30 Mar 2023 23:58:06 +0300
> > > 
> > > Given release is pretty close, how about at least replacing the emoji to
> > > radio
> > > button? 🔘 This way it would be clearly a button, and also wouldn't have
> > > any
> > > reds in it
> > 
> > Who says this character is widespread enough for us to use it?
> 
> 🔘 was approved to Unicode in 2010¹. In comparison, the ⛔ character being used
> now was approved in 2009². Also, both characters were part of the same release
> Emoji Version 1.0.
> 
> So I guess, there shouldn't be much difference?
> 
> > Anyway, I see no reason to rush with this.  The current situation is
> > not really that bad, considering that these messages should not be
> > shown too frequently.
> 
> My experience is the opposite, which is why I'm pinging this issue. When
> native
> compilation is enabled (which is guess is what we'd prefer to see as it
> improves
> performance for our users), it is shown every time stuff from ELPA gets byte-
> recompiled. That is, every time you install or update packages, you will get
> some warnings.

Actually, scratch that, it's even worse. You see: the byte-compiled packages are
natively-compiled on demand, i.e. on the first use. So, suppose you updated your
(M)ELPA packages. What happens is that you get a bunch of warnings for packages
that were loaded immediately, which is not all of them. During Emacs use later,
as you open new files that weren't opened during the update thus triggering the
according modes to load, you will get more and more new warnings.

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 60854@debbugs.gnu.org
> Date: Fri, 31 Mar 2023 09:26:38 +0300
> 
> Actually, scratch that, it's even worse. You see: the byte-compiled
> packages are natively-compiled on demand, i.e. on the first use. So,
> suppose you updated your (M)ELPA packages. What happens is that you
> get a bunch of warnings for packages that were loaded immediately,
> which is not all of them. During Emacs use later, as you open new
> files that weren't opened during the update thus triggering the
> according modes to load, you will get more and more new warnings.

Emacs 28 with native-compilation was released a year ago.  MELPA
packages should have adapted to that long ago, by fixing the problems
which cause those warnings.  My suggestion is to file issues with the
respective developers and pinging them until they resolve this.  In
almost all cases, these warnings are due to missing 'require's or
other similar omissions.  There's no justification for these problems
to exist in the year 2023.

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

On Fri, 2023-03-31 at 10:05 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: 60854@debbugs.gnu.org
> > Date: Fri, 31 Mar 2023 09:26:38 +0300
> > 
> > Actually, scratch that, it's even worse. You see: the byte-compiled
> > packages are natively-compiled on demand, i.e. on the first use. So,
> > suppose you updated your (M)ELPA packages. What happens is that you
> > get a bunch of warnings for packages that were loaded immediately,
> > which is not all of them. During Emacs use later, as you open new
> > files that weren't opened during the update thus triggering the
> > according modes to load, you will get more and more new warnings.
> 
> Emacs 28 with native-compilation was released a year ago.  MELPA
> packages should have adapted to that long ago, by fixing the problems
> which cause those warnings.  My suggestion is to file issues with the
> respective developers and pinging them until they resolve this.  In
> almost all cases, these warnings are due to missing 'require's or
> other similar omissions.  There's no justification for these problems
> to exist in the year 2023.

FWIW, I co-maintain a color-identifiers mode on github, and I have occasionally
introduced new native-comp warnings (about a variable being referred in a
function before its `defvar`). This happens because you debug and test ELisp
code without it being compiled at all. Then later after everything seems to
work, you test that byte-compilation produces no warnings. But at that point you
don't know there isn't any warnings from native-comp, so you also need to load
the byte-compiled file, which is easy to forget.

That, and given that some modes in (M)Elpa may be unmaintained — I don't see
native-comp warnings go away any time soon.

I do sympathise your wish to improve (M)Elpa packages. But the discussed problem
with the wrong emoji shown is not a problem of those modes, it's the Emacs
problem. When you see "BIG RED ERROR" for a harmless warning from a `foo-mode`,
the bad experience is not related to `foo-mode` but to Emacs that disturbs a
user for no reason.

Simply changing emoji would still show interested users there is a problem with
their mode that they can fix, but at the same time would avoid attributing
negative experience to Emacs per se.

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 60854@debbugs.gnu.org
> Date: Fri, 31 Mar 2023 10:48:12 +0300
> 
> FWIW, I co-maintain a color-identifiers mode on github, and I have occasionally
> introduced new native-comp warnings (about a variable being referred in a
> function before its `defvar`). This happens because you debug and test ELisp
> code without it being compiled at all. Then later after everything seems to
> work, you test that byte-compilation produces no warnings. But at that point you
> don't know there isn't any warnings from native-comp, so you also need to load
> the byte-compiled file, which is easy to forget.

Better testing should fix these.

> That, and given that some modes in (M)Elpa may be unmaintained — I don't see
> native-comp warnings go away any time soon.

Well, they went away in Emacs a long time ago.  So it's doable.

> Simply changing emoji would still show interested users there is a problem with
> their mode that they can fix, but at the same time would avoid attributing
> negative experience to Emacs per se.

Feel free to suggest defcustoms to allow users to customize the
symbols.  That should leave everyone happy.

In any case, it's too late to suggest such changes for the emacs-29
branch.

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

On Fri, 2023-03-31 at 10:54 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: 60854@debbugs.gnu.org
> > Date: Fri, 31 Mar 2023 10:48:12 +0300
> > 
> > FWIW, I co-maintain a color-identifiers mode on github, and I have
> > occasionally
> > introduced new native-comp warnings (about a variable being referred in a
> > function before its `defvar`). This happens because you debug and test ELisp
> > code without it being compiled at all. Then later after everything seems to
> > work, you test that byte-compilation produces no warnings. But at that point
> > you
> > don't know there isn't any warnings from native-comp, so you also need to
> > load
> > the byte-compiled file, which is easy to forget.
> 
> Better testing should fix these.

Sure. Setting up a CI to run upon PRs before they're merged would be ideal. But
I don't believe people will start doing that just because there is native-comp
now.

> > That, and given that some modes in (M)Elpa may be unmaintained — I don't see
> > native-comp warnings go away any time soon.
> 
> Well, they went away in Emacs a long time ago.  So it's doable.

Last I checked Emacs was maintained 😄 For unmaintained modes there will be
simply no one to merge fixes that someone creates.

> > Simply changing emoji would still show interested users there is a problem
> > with
> > their mode that they can fix, but at the same time would avoid attributing
> > negative experience to Emacs per se.
> 
> Feel free to suggest defcustoms to allow users to customize the
> symbols.  That should leave everyone happy.

The problem is about OOTB behaviour. (although now that I think about that, Doom
Emacs which seems quite popular could maybe replace the emoji in their config.
Hmm…)

> In any case, it's too late to suggest such changes for the emacs-29
> branch.

I see. Oh, well…

bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 60854@debbugs.gnu.org
> Date: Fri, 31 Mar 2023 09:19:26 +0300
> 
> On Fri, 2023-03-31 at 08:55 +0300, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > Date: Thu, 30 Mar 2023 23:58:06 +0300
> > > 
> > > Given release is pretty close, how about at least replacing the emoji to
> > > radio
> > > button? 🔘 This way it would be clearly a button, and also wouldn't have any
> > > reds in it
> > 
> > Who says this character is widespread enough for us to use it?
> 
> 🔘 was approved to Unicode in 2010¹. In comparison, the ⛔ character being used
> now was approved in 2009². Also, both characters were part of the same release
> Emoji Version 1.0.
> 
> So I guess, there shouldn't be much difference?

What matters for Emacs is the support of these characters by popular
fonts out there, not since when are their codepoints defined.

> > Anyway, I see no reason to rush with this.  The current situation is
> > not really that bad, considering that these messages should not be
> > shown too frequently.
> 
> My experience is the opposite, which is why I'm pinging this issue. When native
> compilation is enabled (which is guess is what we'd prefer to see as it improves
> performance for our users), it is shown every time stuff from ELPA gets byte-
> recompiled. That is, every time you install or update packages, you will get
> some warnings.

My advice is to invest efforts in fixing the problems which cause
those warnings instead of in looking for better symbols that are shown
when the warnings are emitted.