* bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign @ 2023-02-11 8:45 Konstantin Kharlamov [not found] ` <handler.61413.B.16761051946467.ack@debbugs.gnu.org> 2023-02-11 10:36 ` bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Konstantin Kharlamov @ 2023-02-11 8:45 UTC (permalink / raw) To: 61413 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 ^ permalink raw reply related [flat|nested] 13+ messages in thread
[parent not found: <handler.61413.B.16761051946467.ack@debbugs.gnu.org>]
* bug#61413: Acknowledgement ([PATCH] Make warnings show a "warning" emoji instead of a stop-sign) [not found] ` <handler.61413.B.16761051946467.ack@debbugs.gnu.org> @ 2023-02-11 8:49 ` Konstantin Kharlamov 0 siblings, 0 replies; 13+ messages in thread From: Konstantin Kharlamov @ 2023-02-11 8:49 UTC (permalink / raw) To: 61413 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-02-11 8:45 bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign Konstantin Kharlamov [not found] ` <handler.61413.B.16761051946467.ack@debbugs.gnu.org> @ 2023-02-11 10:36 ` Eli Zaretskii 2023-02-11 10:56 ` bug#60854: " Konstantin Kharlamov 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2023-02-11 10:36 UTC (permalink / raw) To: Konstantin Kharlamov; +Cc: 61413 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-02-11 10:36 ` bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign Eli Zaretskii @ 2023-02-11 10:56 ` Konstantin Kharlamov 2023-03-30 20:58 ` bug#60854: " Konstantin Kharlamov 0 siblings, 1 reply; 13+ messages in thread From: Konstantin Kharlamov @ 2023-02-11 10:56 UTC (permalink / raw) To: 60854 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-02-11 10:56 ` bug#60854: " Konstantin Kharlamov @ 2023-03-30 20:58 ` Konstantin Kharlamov 2023-03-31 5:55 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Konstantin Kharlamov @ 2023-03-30 20:58 UTC (permalink / raw) To: 60854 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-30 20:58 ` bug#60854: " Konstantin Kharlamov @ 2023-03-31 5:55 ` Eli Zaretskii 2023-03-31 6:19 ` Konstantin Kharlamov 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2023-03-31 5:55 UTC (permalink / raw) To: Konstantin Kharlamov; +Cc: 60854 > 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.) ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-31 5:55 ` Eli Zaretskii @ 2023-03-31 6:19 ` Konstantin Kharlamov 2023-03-31 6:26 ` Konstantin Kharlamov 2023-03-31 7:00 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Konstantin Kharlamov @ 2023-03-31 6:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 60854 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-31 6:19 ` Konstantin Kharlamov @ 2023-03-31 6:26 ` Konstantin Kharlamov 2023-03-31 7:05 ` Eli Zaretskii 2023-03-31 7:00 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Konstantin Kharlamov @ 2023-03-31 6:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 60854 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-31 6:26 ` Konstantin Kharlamov @ 2023-03-31 7:05 ` Eli Zaretskii 2023-03-31 7:48 ` Konstantin Kharlamov 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2023-03-31 7:05 UTC (permalink / raw) To: Konstantin Kharlamov; +Cc: 60854 > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-31 7:05 ` Eli Zaretskii @ 2023-03-31 7:48 ` Konstantin Kharlamov 2023-03-31 7:54 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Konstantin Kharlamov @ 2023-03-31 7:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 60854 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-31 7:48 ` Konstantin Kharlamov @ 2023-03-31 7:54 ` Eli Zaretskii 2023-03-31 8:10 ` Konstantin Kharlamov 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2023-03-31 7:54 UTC (permalink / raw) To: Konstantin Kharlamov; +Cc: 60854 > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-31 7:54 ` Eli Zaretskii @ 2023-03-31 8:10 ` Konstantin Kharlamov 0 siblings, 0 replies; 13+ messages in thread From: Konstantin Kharlamov @ 2023-03-31 8:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 60854 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… ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign 2023-03-31 6:19 ` Konstantin Kharlamov 2023-03-31 6:26 ` Konstantin Kharlamov @ 2023-03-31 7:00 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2023-03-31 7:00 UTC (permalink / raw) To: Konstantin Kharlamov; +Cc: 60854 > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-03-31 8:10 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-02-11 8:45 bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign Konstantin Kharlamov [not found] ` <handler.61413.B.16761051946467.ack@debbugs.gnu.org> 2023-02-11 8:49 ` bug#61413: Acknowledgement ([PATCH] Make warnings show a "warning" emoji instead of a stop-sign) Konstantin Kharlamov 2023-02-11 10:36 ` bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign Eli Zaretskii 2023-02-11 10:56 ` bug#60854: " Konstantin Kharlamov 2023-03-30 20:58 ` bug#60854: " Konstantin Kharlamov 2023-03-31 5:55 ` Eli Zaretskii 2023-03-31 6:19 ` Konstantin Kharlamov 2023-03-31 6:26 ` Konstantin Kharlamov 2023-03-31 7:05 ` Eli Zaretskii 2023-03-31 7:48 ` Konstantin Kharlamov 2023-03-31 7:54 ` Eli Zaretskii 2023-03-31 8:10 ` Konstantin Kharlamov 2023-03-31 7:00 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.