GNU bug report logs - #60854
Adjust icons shown with warnings

Previous Next

To reply to this bug, email your comments to 60854 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Adjust icons shown with warnings
Date: Mon, 16 Jan 2023 08:35:10 +0100

[Message part 1 (text/plain, inline)]

Currently, warnings are visually "enhanced" with a ⛔ sign.
However, the warning signs are ⚠️ or its slightly different European
version.

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Message part 2 (text/html, inline)]

Message #8 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Mon, 16 Jan 2023 10:58:02 +0100

Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com> writes:

> Currently, warnings are visually "enhanced" with a ⛔ sign.
> However, the warning signs are ⚠️ or its slightly different European
> version.

I had the same question as you, but it turns out that the ⛔ icon is not
intended to represent a warning, it is a button that you can click to
*suppress* that warning type.

Perhaps we can choose a different Emoji to avoid confusion.  I don't
mind showing ⚠️ as the icon for that button, indeed.

Message #11 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Mon, 16 Jan 2023 13:22:33 +0100

[Message part 1 (text/plain, inline)]

Yes, it would create less confusion IMvvvHO

Thanks, /PA

On Mon, 16 Jan 2023 at 10:58, Daniel Martín <mardani29 <at> yahoo.es> wrote:

> Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com> writes:
>
> > Currently, warnings are visually "enhanced" with a ⛔ sign.
> > However, the warning signs are ⚠️ or its slightly different European
> > version.
>
> I had the same question as you, but it turns out that the ⛔ icon is not
> intended to represent a warning, it is a button that you can click to
> *suppress* that warning type.
>
> Perhaps we can choose a different Emoji to avoid confusion.  I don't
> mind showing ⚠️ as the icon for that button, indeed.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Message part 2 (text/html, inline)]

Message #14 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Daniel Martín <mardani29 <at> yahoo.es>,
 Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Mon, 16 Jan 2023 11:30:10 -0800

On 1/16/2023 1:58 AM, Daniel Martín via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com> writes:
> 
>> Currently, warnings are visually "enhanced" with a ⛔ sign.
>> However, the warning signs are ⚠️ or its slightly different European
>> version.
> 
> I had the same question as you, but it turns out that the ⛔ icon is not
> intended to represent a warning, it is a button that you can click to
> *suppress* that warning type.

I think the confusion is that the literal meaning of the ⛔ icon is "No 
Entry", so it's very easy to read it as, "Stop! Don't go this way 
because there's a problem ahead."

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.

Another way to handle the UI (which I see more often, and personally 
prefer) is that the button is a toggle, and its icon indicates the 
current state. This would require adding a bit of code so that clicking 
the button again *un*suppresses the warning, but then you could use 
something like ⚠️ to indicate that the warning is currently enabled (and 
clicking it will suppress it), and maybe ⚪ or ⚬ to indicate that the 
warning is currently suppressed (and clicking it will reenable it). Or 
maybe ❗ and ❕, respectively?

We could also add actual images for this icon if none of these are quite 
right, and use the emoji as a fallback.

Message #17 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 60854 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Tue, 17 Jan 2023 10:56:44 +0100

From a European driver’s POV, the signs that seemed to make most sense to me on the other side of the pond were the warning signs, maybe because they were triangles too…

;-)

/PA

Enviado desde mi iPhone

> El 16 ene 2023, a las 20:30, Jim Porter <jporterbugs <at> gmail.com> escribió:
> 
> On 1/16/2023 1:58 AM, Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
>> Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com> writes:
>>> Currently, warnings are visually "enhanced" with a ⛔ sign.
>>> However, the warning signs are ⚠️ or its slightly different European
>>> version.
>> I had the same question as you, but it turns out that the ⛔ icon is not
>> intended to represent a warning, it is a button that you can click to
>> *suppress* that warning type.
> 
> I think the confusion is that the literal meaning of the ⛔ icon is "No Entry", so it's very easy to read it as, "Stop! Don't go this way because there's a problem ahead."
> 
> 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.
> 
> Another way to handle the UI (which I see more often, and personally prefer) is that the button is a toggle, and its icon indicates the current state. This would require adding a bit of code so that clicking the button again *un*suppresses the warning, but then you could use something like ⚠️ to indicate that the warning is currently enabled (and clicking it will suppress it), and maybe ⚪ or ⚬ to indicate that the warning is currently suppressed (and clicking it will reenable it). Or maybe ❗ and ❕, respectively?
> 
> We could also add actual images for this icon if none of these are quite right, and use the emoji as a fallback.

Message #20 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>, 60854 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Tue, 17 Jan 2023 23:19:55 +0100

(Passing by, can't remember the whole thread, sorry if what I'm
suggesting has already be said)

Jim Porter <jporterbugs <at> gmail.com> writes:

> On 1/16/2023 1:58 AM, Daniel Martín via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>> Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com> writes:
>> 
>>> Currently, warnings are visually "enhanced" with a ⛔ sign.
>>> However, the warning signs are ⚠️ or its slightly different European
>>> version.
>> I had the same question as you, but it turns out that the ⛔ icon is not
>> intended to represent a warning, it is a button that you can click to
>> *suppress* that warning type.
>
> I think the confusion is that the literal meaning of the ⛔ icon is "No Entry",
> so it's very easy to read it as, "Stop! Don't go this way because there's a
> problem ahead."
>
> 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?)

> We could also add actual images for this icon if none of these are quite right,
> and use the emoji as a fallback.

The new icons.el that comes with Emacs 29 would be a prime candidate for
implementing this, right?  It has the advantage of giving the user some
degree of control via icon-preference.

Message #23 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>, 60854 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Tue, 17 Jan 2023 17:37:15 -0800

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.

> The new icons.el that comes with Emacs 29 would be a prime candidate for
> implementing this, right?  It has the advantage of giving the user some
> degree of control via icon-preference.

Yup, the icon we have today is implemented via icons.el:

  (define-icon warnings-suppress button
    '((emoji "⛔")
      (symbol " ■ ")
      (text " stop "))
    "Suppress warnings."
    :version "29.1"
    :help-echo "Click to suppress this warning type")

Message #26 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>, 60854 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Wed, 18 Jan 2023 07:51:19 +0100

Jim Porter <jporterbugs <at> gmail.com> writes:

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

Sure, the toggle sounds like a nice idea regardless, since IIUC right
now a user has to go through Customize to take warnings off either
warning-suppress-*types.

(Sorry for the idle musing, this is the first time I look at what knobs
 warnings.el lets the user tweak.

 As things stand, if a user doesn't want to completely ignore a warning,
 their only choices seem to be "pop *Warnings*" or "meh, tuck it in
 *Warnings* but don't pop; hopefully I'll remember to check that buffer
 someday", is that correct?

 Might be nice to have further options for "suppression", e.g.…

 "don't pop the *Warnings* buffer, but display in echo area", or
                               "…  but add a modeline indicator"

 … but that's its own feature request)

>> The new icons.el that comes with Emacs 29 would be a prime candidate for
>> implementing this, right?  It has the advantage of giving the user some
>> degree of control via icon-preference.
>
> Yup, the icon we have today is implemented via icons.el:
>
>   (define-icon warnings-suppress button
>     '((emoji "⛔")
>       (symbol " ■ ")
>       (text " stop "))
>     "Suppress warnings."
>     :version "29.1"
>     :help-echo "Click to suppress this warning type")

(Ah, great, so we're only missing an 'image entry for that one.  Just a
trivial matter of choosing what the image should look like then 😁)

Thanks for the answers 🙏

Message #29 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Jim Porter <jporterbugs <at> gmail.com>,
 Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>, 60854 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Wed, 18 Jan 2023 11:30:38 +0100

>>>>> On Wed, 18 Jan 2023 07:51:19 +0100, Kévin Le Gouguec <kevin.legouguec <at> gmail.com> said:

    Kévin> Jim Porter <jporterbugs <at> gmail.com> writes:
    >> 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.

    Kévin> Sure, the toggle sounds like a nice idea regardless, since IIUC right
    Kévin> now a user has to go through Customize to take warnings off either
    Kévin> warning-suppress-*types.

    Kévin> (Sorry for the idle musing, this is the first time I look at what knobs
    Kévin>  warnings.el lets the user tweak.

    Kévin>  As things stand, if a user doesn't want to completely ignore a warning,
    Kévin>  their only choices seem to be "pop *Warnings*" or "meh, tuck it in
    Kévin>  *Warnings* but don't pop; hopefully I'll remember to check that buffer
    Kévin>  someday", is that correct?

Yes

    Kévin>  Might be nice to have further options for "suppression", e.g.…

    Kévin>  "don't pop the *Warnings* buffer, but display in echo area", or
    Kévin>                                "…  but add a modeline indicator"

    Kévin>  … but that's its own feature request)

Sure. Just donʼt turn that on by default :-)

    >>> The new icons.el that comes with Emacs 29 would be a prime candidate for
    >>> implementing this, right?  It has the advantage of giving the user some
    >>> degree of control via icon-preference.
    >> 
    >> Yup, the icon we have today is implemented via icons.el:
    >> 
    >>   (define-icon warnings-suppress button
    >> '((emoji "⛔")
    >> (symbol " ■ ")
    >> (text " stop "))
    >> "Suppress warnings."
    >> :version "29.1"
    >> :help-echo "Click to suppress this warning type")

    Kévin> (Ah, great, so we're only missing an 'image entry for that one.  Just a
    Kévin> trivial matter of choosing what the image should look like then 😁)

Whilst youʼre changing stuff, the text should not be "stop", it should
be "suppress" or "ignore" or something.

Robert
-- 

Message #32 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <salutis <at> me.com>
To: Daniel Martín <mardani29 <at> yahoo.es>, Pedro Andres Aranda
 Gutierrez <paaguti <at> gmail.com>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: Adjust icons shown with warnings
Date: Sun, 22 Jan 2023 22:36:53 +0100

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> [...] but it turns out that the ⛔ icon is not intended to represent a
> warning, it is a button that you can click to *suppress* that warning type.

Wow!  I have used computers for decades, and I would have never guessed that one
can click the emoji icon to suppress the warning type.  Using Emojis as UI icons
almost always backfires and personally, I find none of the icons proposed in
this thread clear.  But even if I did, I would have never guessed that they
function as buttons.

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Message #37 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: 60854 <at> debbugs.gnu.org
Subject: Re: bug#61413: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Sat, 11 Feb 2023 13:56:49 +0300

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.

Message #40 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Thu, 30 Mar 2023 23:58:06 +0300

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

Message #43 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Fri, 31 Mar 2023 08:55:47 +0300

> From: Konstantin Kharlamov <hi-angel <at> 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.)

Message #46 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
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 <at> 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/

Message #49 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Fri, 31 Mar 2023 09:26:38 +0300

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 <at> 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.

Message #52 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Fri, 31 Mar 2023 10:00:04 +0300

> From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> Cc: 60854 <at> 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 <at> 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.

Message #55 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Fri, 31 Mar 2023 10:05:56 +0300

> From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> Cc: 60854 <at> 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.

Message #58 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Fri, 31 Mar 2023 10:48:12 +0300

On Fri, 2023-03-31 at 10:05 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> > Cc: 60854 <at> 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.

Message #61 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Fri, 31 Mar 2023 10:54:57 +0300

> From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> Cc: 60854 <at> 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.

Message #64 received at 60854 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60854 <at> debbugs.gnu.org
Subject: Re: bug#60854: [PATCH] Make warnings show a "warning" emoji instead
 of a stop-sign
Date: Fri, 31 Mar 2023 11:10:25 +0300

On Fri, 2023-03-31 at 10:54 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> > Cc: 60854 <at> 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…

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.