GNU bug report logs -
#61413
[PATCH] Make warnings show a "warning" emoji instead of a stop-sign
Previous Next
To reply to this bug, email your comments to 61413 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 11 Feb 2023 08:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Konstantin Kharlamov <Hi-Angel <at> yandex.ru>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 11 Feb 2023 08:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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))
(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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 11 Feb 2023 08:50:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 61413 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 11 Feb 2023 10:37:06 GMT)
Full text and
rfc822 format available.
Message #11 received at 61413 <at> debbugs.gnu.org (full text, mbox):
merge 61413 60854
thanks
> From: Konstantin Kharlamov <Hi-Angel <at> 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.
Merged 60854 61413.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 11 Feb 2023 10:37:07 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 12 Feb 2025 04:53:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
> 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))
>
> (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))
This definitely risks going deep into bikeshedding territory, but in my
view, the Unicode code point "WARNING SIGN" is clearly the better
choice, as it directly conveys a warning.
The Unicode code point "NO ENTRY", meanwhile, is just completely
incomprehensible. No entry to what?
Can we install this?
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 12 Feb 2025 04:53:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 12 Feb 2025 07:23:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
>
>> 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))
>>
>> (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))
>
> This definitely risks going deep into bikeshedding territory, but in my
> view, the Unicode code point "WARNING SIGN" is clearly the better
> choice, as it directly conveys a warning.
>
> The Unicode code point "NO ENTRY", meanwhile, is just completely
> incomprehensible. No entry to what?
>
> Can we install this?
Given the purpose of the button (_suppress_ the warning, not merely
report it) & Konstantin's remark¹ about the intuitive connotations of
red, ISTM
(a) adding an 'image' icon presentation using a neutral-colored SVG, or
(b) as Konstantin suggested, ditching pictograms entirely, and replacing
that icon with a regular text button clearly labeled "suppress",
would be preferable to s/⛔/⚠️: I would not expect users to intuit that
they can suppress warnings by interacting with the warning sign.
¹ Filed under bug#60854 after the merge, FTR.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 12 Feb 2025 10:28:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 61413 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 12 Feb 2025 08:21:52 +0100, Kévin Le Gouguec <kevin.legouguec <at> gmail.com> said:
Kévin> Given the purpose of the button (_suppress_ the warning, not merely
Kévin> report it) & Konstantin's remark¹ about the intuitive connotations of
Kévin> red, ISTM
Kévin> (a) adding an 'image' icon presentation using a neutral-colored SVG, or
Kévin> (b) as Konstantin suggested, ditching pictograms entirely, and replacing
Kévin> that icon with a regular text button clearly labeled "suppress",
Kévin> would be preferable to s/⛔/⚠️: I would not expect users to intuit that
Kévin> they can suppress warnings by interacting with the warning sign.
Weʼd be back at the original implementation then 🙂
Iʼm in favour of that, but Iʼm not neutral here.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Fri, 14 Feb 2025 22:02:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> (b) as Konstantin suggested, ditching pictograms entirely, and replacing
> that icon with a regular text button clearly labeled "suppress"
+1 for a standard, discoverable, and accessible button.
Rudy
--
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
--- Edsger W. Dijkstra, 1981
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Fri, 14 Feb 2025 22:02:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
On terminals which can't display these emojis, please arrange for
Emacs to flag these messages using ASCII characters. Perhaps
set up customization of the way to display them.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 15 Feb 2025 05:28:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> Cc: Hi-Angel <at> yandex.ru, stefankangas <at> gmail.com, 61413 <at> debbugs.gnu.org,
> kevin.legouguec <at> gmail.com
> From: Richard Stallman <rms <at> gnu.org>
> Date: Fri, 14 Feb 2025 17:01:19 -0500
>
> On terminals which can't display these emojis, please arrange for
> Emacs to flag these messages using ASCII characters. Perhaps
> set up customization of the way to display them.
All of that is already done. The replacement can be a special
non-ASCII character or an ASCII one as fallback.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 15 Feb 2025 10:27:01 GMT)
Full text and
rfc822 format available.
Message #36 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
>> (b) as Konstantin suggested, ditching pictograms entirely, and replacing
>> that icon with a regular text button clearly labeled "suppress"
>
> +1 for a standard, discoverable, and accessible button.
Thoughts prompted by this and rms's messages:
* A bona-fide bug:
display-warning *strips* the button's help-echo property:
(insert (buttonize (icon-string 'warnings-suppress)
#'warnings-suppress type)
'buttonize' clobbers the help-echo property added by 'icon-string' ☹️
That does make the current emoji extra-obscure, since hovering over it
gives no clue as to what it does!
Solutions:
(a) display-warning could retrieve the property from the string returned
by icon-string, then spoon-feeding it back to buttonize,
(b) buttonize could check whether its STRING argument has a help-echo
property before clobbering it with nil,
(c) we invent a sentinel value for buttonize's HELP-ECHO argument to
mean "psst, STRING already has the right help-echo property; use that".
* A general remark:
For users to whom emoji presentation _in general_ is not accessible
enough, the icon-preference option can be set to 'text to always get "a
regular text button clearly labeled <something>".
Thought it bore mention since the present report is about bikeshedding
the graphical representation of the warnings-suppress icon, whereas
Rudolf's reply suggests - to me - a wider wish to be able to opt out of
these representations: this is already solved.
* A caveat for terminals:
As Eli mentions, icons.el already knows to fall back to a suitable
representation on TTYs. In practice though, the Linux TTY can display a
few non-ASCII characters; as a result, here (6.13 if that matters) Emacs
falls back to warnings-suppress's _symbol_ representation…
(symbol ,(if (and (eq system-type 'windows-nt)
(null window-system))
" » "
" ■ ")) ; 👈 that one
… which one could bikeshed too, if one were so inclined 🫣
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 15 Feb 2025 22:41:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> 'buttonize' clobbers the help-echo property added by 'icon-string' ☹️
> That does make the current emoji extra-obscure, since hovering over it
> gives no clue as to what it does!
>
> Solutions:
>
> (a) display-warning could retrieve the property from the string returned
> by icon-string, then spoon-feeding it back to buttonize,
> (b) buttonize could check whether its STRING argument has a help-echo
> property before clobbering it with nil,
> (c) we invent a sentinel value for buttonize's HELP-ECHO argument to
> mean "psst, STRING already has the right help-echo property; use that".
See attached patches. No intuition which is best; I guess (a) is the
least disruptive - no change in the semantics of 'buttonize'.
I wonder how critical we think finding a new graphical representation
for that button feels now, considering that once this is fixed,
mouse-hovering & C-h . will let users now what that button is for.
[a-spoonfeed.patch (text/x-patch, attachment)]
[b-fallback.patch (text/x-patch, attachment)]
[c-sentinel.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 15 Feb 2025 22:51:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> * A caveat for terminals:
>
> As Eli mentions, icons.el already knows to fall back to a suitable
> representation on TTYs. In practice though, the Linux TTY can display a
> few non-ASCII characters; as a result, here (6.13 if that matters) Emacs
> falls back to warnings-suppress's _symbol_ representation…
>
> (symbol ,(if (and (eq system-type 'windows-nt)
> (null window-system))
> " » "
> " ■ ")) ; 👈 that one
>
> … which one could bikeshed too, if one were so inclined 🫣
Over at bug#60854, I note that Robert mentioned:
> Whilst youʼre changing stuff, the text should not be "stop", it should
> be "suppress" or "ignore" or something.
Referring to the current 'text presentation.
In light of all this, how do we feel about the attached patch? (FTR,
"×" displays fine in a Linux TTY here; I do not have a Windows console
handy however so that patch might go overboard)
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 15 Feb 2025 23:00:03 GMT)
Full text and
rfc822 format available.
Message #45 received at 61413 <at> debbugs.gnu.org (full text, mbox):
On Sat, 2025-02-15 at 23:50 +0100, Kévin Le Gouguec wrote:
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
> > * A caveat for terminals:
> >
> > As Eli mentions, icons.el already knows to fall back to a suitable
> > representation on TTYs. In practice though, the Linux TTY can
> > display a
> > few non-ASCII characters; as a result, here (6.13 if that matters)
> > Emacs
> > falls back to warnings-suppress's _symbol_ representation…
> >
> > (symbol ,(if (and (eq system-type 'windows-nt)
> > (null window-system))
> > " » "
> > " ■ ")) ; 👈 that one
> >
> > … which one could bikeshed too, if one were so inclined 🫣
>
> Over at bug#60854, I note that Robert mentioned:
>
> > Whilst youʼre changing stuff, the text should not be "stop", it
> > should
> > be "suppress" or "ignore" or something.
>
> Referring to the current 'text presentation.
>
> In light of all this, how do we feel about the attached patch? (FTR,
> "×" displays fine in a Linux TTY here; I do not have a Windows
> console
> handy however so that patch might go overboard)
"suppress" yes, but does this also replace "stop" emoji to " × ", am I
understanding that correctly? Why if so? To me such emoji doesn't seem
to be any better than "stop".
I imagine, best solution is to just have a clear button labeled
"suppress", as was discussed up-thread, and no one seem to have
objected. It has no misinterpretation problem. It's just I don't know
whether it would be complicated to implement…
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sun, 16 Feb 2025 06:18:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> Cc: Robert Pluim <rpluim <at> gmail.com>, Konstantin Kharlamov <Hi-Angel <at> yandex.ru>,
> rms <at> gnu.org, 61413 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Sat, 15 Feb 2025 23:50:08 +0100
>
> In light of all this, how do we feel about the attached patch? (FTR,
> "×" displays fine in a Linux TTY here;
Beware: the characters supported by a Linux console can be changed
programmatically. We should use char-displayable-p to find out
whether a given character is or isn't supported.
> I do not have a Windows console handy
With the current way we write characters to the Windows terminal, "×"
shows as "\u00D7" (because it is not part of any windows-125x
encoding), so no. (We should really work on improving our Windows
console output code, because on most modern Windows installation the
font used by the Windows terminal does support that character, and
even supports color Emoji.)
So my suggestion is to have several potential characters, all the way
down to ASCII, and test their usability using char-displayable-p, not
using system-type or similar indirect evidence.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sun, 16 Feb 2025 09:29:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
>> In light of all this, how do we feel about the attached patch? (FTR,
>> "×" displays fine in a Linux TTY here; I do not have a Windows
>> console
>> handy however so that patch might go overboard)
>
> "suppress" yes, but does this also replace "stop" emoji to " × ", am I
> understanding that correctly? Why if so? To me such emoji doesn't seem
> to be any better than "stop".
To clarify, the patch you are commenting on does not change nor remove
the 'emoji presentation, only 'symbol (■ to ×, to address the default
console look; as Eli explains, needs refinement) and 'text ("stop" to
"suppress", per Robert's suggestion).
TBH, as far as I am concerned, the discussion re. presentation has been
eclipsed by the 'help-echo clobbering. So seeking thoughts on the 3
patches there:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#39>
<87a5amal2t.fsf <at> gmail.com>
Regardless of presentation changes, ISTM we should restore the tooltip
on hovering and the message on 'C-h .'.
> I imagine, best solution is to just have a clear button labeled
> "suppress", as was discussed up-thread, and no one seem to have
> objected. It has no misinterpretation problem. It's just I don't know
> whether it would be complicated to implement…
Two thoughts:
1. Unless I missed something, we *all* collectively missed a glaring
*functional* problem with that button: its help-echo string being
stripped. IMO we could give ⛔ a "second chance" in light of that.
2. Back to your point, if we deem that emoji irredeemable, the level of
complication depends on what implementation we choose:
(a) Punt to the users: tell them "set icon-preference to '(text)".
Trivial, but not user-friendly: *all* icons will be turned to text,
including those with intuitive graphical forms.
(b) Conclude that there are no satisfying graphical representations of
"warnings-suppress": drop all but the 'text representation of that
icon (in fact, just use a regular button instead of an "icon").
Simple enough, though maybe a regression for thos who think that ⛔ is
Fine™.
(c) Extend icons.el to allow users to adjust representations *per
icon*. Punt to the users *after* giving them the tools to fine-tune
stuff; let folks who find ⛔ obscure set warnings-suppress to 'text or
remove the 'emoji representation.
Somewhat more involved.
No opinion myself. Again, my current focus is on restoring the
help-echo string; ISTM that recontextualizes the whole discussion. *Of
course* that button was obscure *regardless of presentation*: users had
no way of finding out what it does beside C-u C-x h.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Tue, 18 Feb 2025 00:30:03 GMT)
Full text and
rfc822 format available.
Message #54 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> For users to whom emoji presentation _in general_ is not accessible
> enough, the icon-preference option can be set to 'text to always get "a
> regular text button clearly labeled <something>".
It seesm to try to choose automatical the best method.
That is nice.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 00:21:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Thought it bore mention since the present report is about bikeshedding
> the graphical representation of the warnings-suppress icon, whereas
> Rudolf's reply suggests - to me - a wider wish to be able to opt out of
> these representations: this is already solved.
I apologize for not communicating more clearly. What I meant is the
following. While, I can opt out of the "emoji representation", I think
Emacs should always default to standard, discoverable, and accessible
controls.
Say we sampled a group of 10 users, how many of them would know, without
further UI exploration, that the emoji is a button and what it does? If
fewer than 10, then we should ask, "why are we doing this" and stop.
As for me, I think these emoji buttons are a bad idea to start with, let
alone to continue with, let alone work around the newly discovered
problems with them.
Rudy
--
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place."
--- Immanuel Kant, 1785
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 02:02:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
>> Thought it bore mention since the present report is about bikeshedding
>> the graphical representation of the warnings-suppress icon, whereas
>> Rudolf's reply suggests - to me - a wider wish to be able to opt out of
>> these representations: this is already solved.
>
> I apologize for not communicating more clearly. What I meant is the
> following. While, I can opt out of the "emoji representation", I think
> Emacs should always default to standard, discoverable, and accessible
> controls.
>
> Say we sampled a group of 10 users, how many of them would know, without
> further UI exploration, that the emoji is a button and what it does? If
> fewer than 10, then we should ask, "why are we doing this" and stop.
>
> As for me, I think these emoji buttons are a bad idea to start with, let
> alone to continue with, let alone work around the newly discovered
> problems with them.
Maybe we should make them look like the buttons in customize instead?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 02:13:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 61413 <at> debbugs.gnu.org (full text, mbox):
On Wed, 2025-02-19 at 02:01 +0000, Stefan Kangas wrote:
> Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
>
> > Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> >
> > > Thought it bore mention since the present report is about
> > > bikeshedding
> > > the graphical representation of the warnings-suppress icon,
> > > whereas
> > > Rudolf's reply suggests - to me - a wider wish to be able to opt
> > > out of
> > > these representations: this is already solved.
> >
> > I apologize for not communicating more clearly. What I meant is
> > the
> > following. While, I can opt out of the "emoji representation", I
> > think
> > Emacs should always default to standard, discoverable, and
> > accessible
> > controls.
> >
> > Say we sampled a group of 10 users, how many of them would know,
> > without
> > further UI exploration, that the emoji is a button and what it
> > does? If
> > fewer than 10, then we should ask, "why are we doing this" and
> > stop.
> >
> > As for me, I think these emoji buttons are a bad idea to start
> > with, let
> > alone to continue with, let alone work around the newly discovered
> > problems with them.
>
> Maybe we should make them look like the buttons in customize instead?
I don't see how that may help. A user may or may not look at
customization page for the warnings, whereas the problem is a user
wouldn't know the emoji in compilation buffer is a button, let alone
what it does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 02:58:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
> On Wed, 2025-02-19 at 02:01 +0000, Stefan Kangas wrote:
>> Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
>>
>> > Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>> >
>> > > Thought it bore mention since the present report is about
>> > > bikeshedding
>> > > the graphical representation of the warnings-suppress icon,
>> > > whereas
>> > > Rudolf's reply suggests - to me - a wider wish to be able to opt
>> > > out of
>> > > these representations: this is already solved.
>> >
>> > I apologize for not communicating more clearly. What I meant is
>> > the
>> > following. While, I can opt out of the "emoji representation", I
>> > think
>> > Emacs should always default to standard, discoverable, and
>> > accessible
>> > controls.
>> >
>> > Say we sampled a group of 10 users, how many of them would know,
>> > without
>> > further UI exploration, that the emoji is a button and what it
>> > does? If
>> > fewer than 10, then we should ask, "why are we doing this" and
>> > stop.
>> >
>> > As for me, I think these emoji buttons are a bad idea to start
>> > with, let
>> > alone to continue with, let alone work around the newly discovered
>> > problems with them.
>>
>> Maybe we should make them look like the buttons in customize instead?
>
> I don't see how that may help. A user may or may not look at
> customization page for the warnings, whereas the problem is a user
> wouldn't know the emoji in compilation buffer is a button, let alone
> what it does.
We don't use emojis in customize.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 07:25:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
>> Thought it bore mention since the present report is about bikeshedding
>> the graphical representation of the warnings-suppress icon, whereas
>> Rudolf's reply suggests - to me - a wider wish to be able to opt out of
>> these representations: this is already solved.
>
> I apologize for not communicating more clearly. What I meant is the
> following. While, I can opt out of the "emoji representation", I think
> Emacs should always default to standard, discoverable, and accessible
> controls.
>
> Say we sampled a group of 10 users, how many of them would know, without
> further UI exploration, that the emoji is a button and what it does? If
> fewer than 10, then we should ask, "why are we doing this" and stop.
I don't know that I find "without further UI exploration" a useful
condition: because of that help-echo bug, *no* amount of UI exploration
can answer the question "what's this do?" anyway.
So while I do find the current warnings-suppress emoji less-than-ideal
aesthetically (as Stefan suggests, a theme-compliant SVG would look
better¹), I remain convinced that the primary *functional* problem here
is that help-echo bug.
(Which I sent patches for earlier²; however, since no-one commented on
those AFAICT, I suppose I am in the minority in considering this an
immediate and obvious bug that needs addressing)
¹ Which we do use, when we find SVGs we find "good enough" for the job -
see icons defined in e.g. tab-bar.el, tab-line.el, auth-source.el.
¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#39
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 16:00:04 GMT)
Full text and
rfc822 format available.
Message #72 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> Cc: rms <at> gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, 61413 <at> debbugs.gnu.org,
> Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Wed, 19 Feb 2025 08:24:17 +0100
>
> Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
>
> So while I do find the current warnings-suppress emoji less-than-ideal
> aesthetically (as Stefan suggests, a theme-compliant SVG would look
> better¹), I remain convinced that the primary *functional* problem here
> is that help-echo bug.
>
> (Which I sent patches for earlier²; however, since no-one commented on
> those AFAICT, I suppose I am in the minority in considering this an
> immediate and obvious bug that needs addressing)
There's been only 3 days since you sent the patch. We don't always
have enough manpower to move so quickly, especially when the right way
of fixing this is not clear, and you proposed 3 possible ways to
choose from.
> ¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#39
Mauro, could you please help with reviewing the patches and
recommending which fix is in your opinion the best one?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 17:50:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: rms <at> gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
>> 61413 <at> debbugs.gnu.org,
>> Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
>> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
>> Date: Wed, 19 Feb 2025 08:24:17 +0100
>>
>> Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
>>
>> So while I do find the current warnings-suppress emoji less-than-ideal
>> aesthetically (as Stefan suggests, a theme-compliant SVG would look
>> better¹), I remain convinced that the primary *functional* problem here
>> is that help-echo bug.
>>
>> (Which I sent patches for earlier²; however, since no-one commented on
>> those AFAICT, I suppose I am in the minority in considering this an
>> immediate and obvious bug that needs addressing)
>
> Mauro, could you please help with reviewing the patches and
> recommending which fix is in your opinion the best one?
>
I'd vote for (b), the fallback.patch. It improves the button
library and doesn't require changes in client code.
I think we'd like something similar for buttonize-region, so I wonder if
it's not better to do the change inside button--properties, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 21:26:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Mauro Aranda <maurooaranda <at> gmail.com> writes:
>>> So while I do find the current warnings-suppress emoji less-than-ideal
>>> aesthetically (as Stefan suggests, a theme-compliant SVG would look
>>> better¹), I remain convinced that the primary *functional* problem here
>>> is that help-echo bug.
>>>
>>> (Which I sent patches for earlier²; however, since no-one commented on
>>> those AFAICT, I suppose I am in the minority in considering this an
>>> immediate and obvious bug that needs addressing)
>>
>> There's been only 3 days since you sent the patch. We don't always
>> have enough manpower to move so quickly, especially when the right way
>> of fixing this is not clear, and you proposed 3 possible ways to
>> choose from.
(Right, apologies for the attitude. I was annoyed with myself for
diluting the help-echo problem by suggesting unrelated changes to the
'symbol and 'text representations of warnings-suppress, and got worried
that the former would go unaddressed. Wish I had been less heavy-handed
in that parenthetical)
>> > ¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#39
>>
>> Mauro, could you please help with reviewing the patches and
>> recommending which fix is in your opinion the best one?
>>
>
> I'd vote for (b), the fallback.patch. It improves the button
> library and doesn't require changes in client code.
One concern I have with (b): might some clients rely on the current
behavior? An unconditional fallback would force them to remove that
text property themselves.
I do not deal with buttons much so no intuition on existing practice; I
could see an argument for either behavior - "better some help message
than none" vs "better no help message than the wrong help message".
> I think we'd like something similar for buttonize-region, so I wonder if
> it's not better to do the change inside button--properties, though.
ACK to improve buttonize-region too. button--properties does not have
access to the information needed to get the fallback help-echo tho
(STRING for buttonize, START END for buttonize-region), are you thinking
of passing that fallback as a new argument, or have I missed something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Wed, 19 Feb 2025 21:42:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>>> > ¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#39
>>>
>>> Mauro, could you please help with reviewing the patches and
>>> recommending which fix is in your opinion the best one?
>>>
>>
>> I'd vote for (b), the fallback.patch. It improves the button
>> library and doesn't require changes in client code.
>
> One concern I have with (b): might some clients rely on the current
> behavior? An unconditional fallback would force them to remove that
> text property themselves.
I suspect they don't, but of course I can't be sure. If we don't want
to risk it, then yes, I'd say (c) is the way to go. I don't like (a)
very much because it's just a workaround.
> I do not deal with buttons much so no intuition on existing practice; I
> could see an argument for either behavior - "better some help message
> than none" vs "better no help message than the wrong help message".
>
>> I think we'd like something similar for buttonize-region, so I wonder if
>> it's not better to do the change inside button--properties, though.
>
> ACK to improve buttonize-region too. button--properties does not have
> access to the information needed to get the fallback help-echo tho
> (STRING for buttonize, START END for buttonize-region), are you thinking
> of passing that fallback as a new argument, or have I missed something?
I was thinking in not overwriting the help-echo property if the
help-echo argument is nil.
Currently, button--properties forces a value for the help-echo property.
So it would be like: If it's nil, don't add the help-echo property to
the property list at all, leaving a previous help-echo property
untouched.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Thu, 20 Feb 2025 06:33:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 19 Feb 2025 18:41:38 -0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudolf <at> adamkovic.org, Hi-Angel <at> yandex.ru,
> rms <at> gnu.org, 61413 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
> > Mauro Aranda <maurooaranda <at> gmail.com> writes:
> >
> >>> > ¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#39
> >>>
> >>> Mauro, could you please help with reviewing the patches and
> >>> recommending which fix is in your opinion the best one?
> >>>
> >>
> >> I'd vote for (b), the fallback.patch. It improves the button
> >> library and doesn't require changes in client code.
> >
> > One concern I have with (b): might some clients rely on the current
> > behavior? An unconditional fallback would force them to remove that
> > text property themselves.
>
> I suspect they don't, but of course I can't be sure.
Since 'buttonize' doesn't remove any other text properties, I would be
surprised to hear that some Lisp program used this as a means to
ignore help-echo property of the STRING argument. In any case,
removing that property before calling 'buttonize' should be simple,
no?
> I was thinking in not overwriting the help-echo property if the
> help-echo argument is nil.
>
> Currently, button--properties forces a value for the help-echo property.
> So it would be like: If it's nil, don't add the help-echo property to
> the property list at all, leaving a previous help-echo property
> untouched.
Yes, and I believe the proposed patch (b) does something very similar?
But I agree that not touching the help-echo is cleaner.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Thu, 20 Feb 2025 10:00:04 GMT)
Full text and
rfc822 format available.
Message #87 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Wed, 19 Feb 2025 18:41:38 -0300
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudolf <at> adamkovic.org,
Hi-Angel <at> yandex.ru,
>> rms <at> gnu.org, 61413 <at> debbugs.gnu.org, stefankangas <at> gmail.com
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>>
>> > Mauro Aranda <maurooaranda <at> gmail.com> writes:
>> >
>> >>> > ¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#39
>> >>>
>> >>> Mauro, could you please help with reviewing the patches and
>> >>> recommending which fix is in your opinion the best one?
>> >>>
>> >>
>> >> I'd vote for (b), the fallback.patch. It improves the button
>> >> library and doesn't require changes in client code.
>> >
>> > One concern I have with (b): might some clients rely on the current
>> > behavior? An unconditional fallback would force them to remove that
>> > text property themselves.
>>
>> I suspect they don't, but of course I can't be sure.
>
> Since 'buttonize' doesn't remove any other text properties, I would be
> surprised to hear that some Lisp program used this as a means to
> ignore help-echo property of the STRING argument. In any case,
> removing that property before calling 'buttonize' should be simple,
> no?
Agreed.
>> I was thinking in not overwriting the help-echo property if the
>> help-echo argument is nil.
>>
>> Currently, button--properties forces a value for the help-echo property.
>> So it would be like: If it's nil, don't add the help-echo property to
>> the property list at all, leaving a previous help-echo property
>> untouched.
>
> Yes, and I believe the proposed patch (b) does something very similar?
It does.
> But I agree that not touching the help-echo is cleaner.
OK, so let's wait for Kevin's patch to improve buttonize-region too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Thu, 20 Feb 2025 21:51:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mauro Aranda <maurooaranda <at> gmail.com> writes:
>>> I think we'd like something similar for buttonize-region, so I wonder if
>>> it's not better to do the change inside button--properties, though.
>>
>> ACK to improve buttonize-region too. button--properties does not have
>> access to the information needed to get the fallback help-echo tho
>> (STRING for buttonize, START END for buttonize-region), are you thinking
>> of passing that fallback as a new argument, or have I missed something?
>
> I was thinking in not overwriting the help-echo property if the
> help-echo argument is nil.
💡 Gotcha. Much cleaner than the original patch - that
(get-text-property 0 …) was not very elegant.
> Currently, button--properties forces a value for the help-echo property.
> So it would be like: If it's nil, don't add the help-echo property to
> the property list at all, leaving a previous help-echo property
> untouched.
How does the attached look?
[0001-Prevent-button.el-from-clearing-help-echo-strings.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Thu, 20 Feb 2025 22:13:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>>>> I think we'd like something similar for buttonize-region, so I
wonder if
>>>> it's not better to do the change inside button--properties, though.
>>>
>>> ACK to improve buttonize-region too. button--properties does not have
>>> access to the information needed to get the fallback help-echo tho
>>> (STRING for buttonize, START END for buttonize-region), are you
thinking
>>> of passing that fallback as a new argument, or have I missed something?
>>
>> I was thinking in not overwriting the help-echo property if the
>> help-echo argument is nil.
>
> 💡 Gotcha. Much cleaner than the original patch - that
> (get-text-property 0 …) was not very elegant.
>
>> Currently, button--properties forces a value for the help-echo property.
>> So it would be like: If it's nil, don't add the help-echo property to
>> the property list at all, leaving a previous help-echo property
>> untouched.
>
> How does the attached look?
I think the change looks good. I've just realized that the other caller
of button--properties might need a tweak.
In unbuttonize-region, we should change this call:
(remove-text-properties start end
(button--properties nil nil nil))
to:
(remove-text-properties start end
;; t to ensure help-echo gets reset.
(button--properties nil nil t))
But, now we don't know if the help-echo property was effectively added
by the library or it was already there :-(. Sadness.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Thu, 20 Feb 2025 23:04:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mauro Aranda <maurooaranda <at> gmail.com> writes:
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
>> How does the attached look?
>
> I think the change looks good. I've just realized that the other caller
> of button--properties might need a tweak.
>
> In unbuttonize-region, we should change this call:
> (remove-text-properties start end
> (button--properties nil nil nil))
>
> to:
> (remove-text-properties start end
> ;; t to ensure help-echo gets reset.
> (button--properties nil nil t))
(Thanks, should have caught that button--properties was called by
unbuttonize-region too 🤦)
> But, now we don't know if the help-echo property was effectively added
> by the library or it was already there :-(. Sadness.
Would the attached address that problem? (To apply on top of the
previous patch; I'll squash it all if we are happy with it)
[fixup.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Thu, 20 Feb 2025 23:30:06 GMT)
Full text and
rfc822 format available.
Message #99 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> But, now we don't know if the help-echo property was effectively added
>> by the library or it was already there :-(. Sadness.
>
> Would the attached address that problem? (To apply on top of the
> previous patch; I'll squash it all if we are happy with it)
Looks good to me, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 22 Feb 2025 18:35:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mauro Aranda <maurooaranda <at> gmail.com> writes:
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
>> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>>
>>> But, now we don't know if the help-echo property was effectively added
>>> by the library or it was already there :-(. Sadness.
>>
>> Would the attached address that problem? (To apply on top of the
>> previous patch; I'll squash it all if we are happy with it)
>
> Looks good to me, thanks.
Alright, here's the squashed patch then - with amended ChangeLog. Let
me know whether it looks OK to install.
Back to the topic of the warnings-suppress icon representations: FWIW, I
toyed with status/dialog-error-symbolic.svg from adwaita-icon-theme, but
could not land on a result I found perfectly harmonious.
* Edited the SVG to remove the foreground color, as we usually do, so
that faces apply to the inserted image,
* but warnings-suppress inherits from the 'button icon, which means the
image gets the 'icon-face; the result looks messy IMO,
* inheriting from nil instead, buttonize's 'button face takes over,
which is somewhat confusing too,
* adding ':face default' to the image spec makes the result less jarring
(to me).
Attaching that experiment as well FTR; not wholly pleased with it
though.
(I wonder whether this part of the 'button icon…
(define-icon button nil
'((image :face icon-button) ; 👈 that one
; …
)
"Base icon for buttons."
:version "29.1")
… is desirable. AFAICT _all_ our in-tree icons inherit from nil instead
of 'button' despite their "button-like" function; wondering to what
extent they are opting out of this ':face icon-button'?)
[0001-Prevent-button.el-from-clearing-help-echo-strings.patch (text/x-patch, attachment)]
[icon-image.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 22 Feb 2025 23:05:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Maybe we should make them look like the buttons in customize instead?
Yup. A button like that, saying Suppress, would do. No guesswork.
Rudy
--
"Genius is 1% inspiration and 99% perspiration."
--- Thomas Alva Edison, 1932
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sun, 23 Feb 2025 16:10:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Back to the topic of the warnings-suppress icon representations: FWIW, I
> toyed with status/dialog-error-symbolic.svg from adwaita-icon-theme, but
> could not land on a result I found perfectly harmonious.
Figured that for all the button.el help-echo noodling, it would not hurt
to give a shot to the most-requested suggestions in this report: show a
warning sign *for presentation only*, and use an explicit plain text
button for suppression.
Attaching the result (patch & screenshot). OT1H it feels like there is
room for further refinement¹, OTOH I prefer to send that iteration first
before building castles in the air.
¹ Integration with warning-prefix-function, varying faces with warning
levels, figuring out what the deal is with invoking 'newline instead of
inserting "\n" directly, using define-button-type & insert-button which
I just learned about…
[0001-Use-plain-text-for-warning-supression-button.patch (text/x-patch, attachment)]
[Screenshot_20250223_163540.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 01 Mar 2025 12:27:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 20 Feb 2025 20:29:00 -0300
> Cc: rudolf <at> adamkovic.org, rms <at> gnu.org, stefankangas <at> gmail.com,
> Hi-Angel <at> yandex.ru, Eli Zaretskii <eliz <at> gnu.org>, 61413 <at> debbugs.gnu.org
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
> > Mauro Aranda <maurooaranda <at> gmail.com> writes:
> >
> >> But, now we don't know if the help-echo property was effectively added
> >> by the library or it was already there :-(. Sadness.
> >
> > Would the attached address that problem? (To apply on top of the
> > previous patch; I'll squash it all if we are happy with it)
>
> Looks good to me, thanks.
If you want me to install some patches, please post them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sun, 02 Mar 2025 11:02:03 GMT)
Full text and
rfc822 format available.
Message #114 received at 61413 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>>
>> > Mauro Aranda <maurooaranda <at> gmail.com> writes:
>> >
>> >> But, now we don't know if the help-echo property was effectively added
>> >> by the library or it was already there :-(. Sadness.
>> >
>> > Would the attached address that problem? (To apply on top of the
>> > previous patch; I'll squash it all if we are happy with it)
>>
>> Looks good to me, thanks.
>
> If you want me to install some patches, please post them.
Thanks for the nudge; re-attaching the patch that makes button.el
preserve help-echo strings; reviewed by Mauro in two parts¹², then
squashed³. I can install it if we think that fix is unambiguously good.
There is another (independent) patch in-flight for changing the
presentation of warnings⁴; no feedback on code nor effect yet.
Personally not very invested in it, but I felt it was important to
explore the other ideas raised in this thread (replacing ⛔ with a
regular text button; adding a warning sign).
¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#93
² https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#99
³ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#102
⁴ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108
[0001-Prevent-button.el-from-clearing-help-echo-strings.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Thu, 06 Mar 2025 13:54:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: Mauro Aranda <maurooaranda <at> gmail.com>, rudolf <at> adamkovic.org,
> rms <at> gnu.org, stefankangas <at> gmail.com, Hi-Angel <at> yandex.ru,
> 61413 <at> debbugs.gnu.org
> Date: Sun, 02 Mar 2025 12:01:15 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Mauro Aranda <maurooaranda <at> gmail.com>
> >>
> >> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> >>
> >> > Mauro Aranda <maurooaranda <at> gmail.com> writes:
> >> >
> >> >> But, now we don't know if the help-echo property was effectively added
> >> >> by the library or it was already there :-(. Sadness.
> >> >
> >> > Would the attached address that problem? (To apply on top of the
> >> > previous patch; I'll squash it all if we are happy with it)
> >>
> >> Looks good to me, thanks.
> >
> > If you want me to install some patches, please post them.
>
> Thanks for the nudge; re-attaching the patch that makes button.el
> preserve help-echo strings; reviewed by Mauro in two parts¹², then
> squashed³. I can install it if we think that fix is unambiguously good.
LGTM, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 08 Mar 2025 17:06:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > If you want me to install some patches, please post them.
>>
>> Thanks for the nudge; re-attaching the patch that makes button.el
>> preserve help-echo strings; reviewed by Mauro in two parts¹², then
>> squashed³. I can install it if we think that fix is unambiguously good.
>
> LGTM, thanks.
Just pushed, thanks for the review.
I'll defer to other participants regarding what should be done next -
e.g. (a) should ⛔ be given a second chance now that it has a help-echo
string, making its function more discoverable; (b) should we use another
symbol; (c) should we eschew images entirely for that function & use a
text button.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Mon, 10 Mar 2025 09:03:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 61413 <at> debbugs.gnu.org (full text, mbox):
On Sat, 2025-03-08 at 18:05 +0100, Kévin Le Gouguec wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > > > If you want me to install some patches, please post them.
> > >
> > > Thanks for the nudge; re-attaching the patch that makes button.el
> > > preserve help-echo strings; reviewed by Mauro in two parts¹²,
> > > then
> > > squashed³. I can install it if we think that fix is
> > > unambiguously good.
> >
> > LGTM, thanks.
>
> Just pushed, thanks for the review.
>
> I'll defer to other participants regarding what should be done next -
> e.g. (a) should ⛔ be given a second chance now that it has a help-
> echo
> string, making its function more discoverable; (b) should we use
> another
> symbol; (c) should we eschew images entirely for that function & use
> a
> text button.
Sorry for stupid question, but… I just wanted to see how do warnings
look now, and I figured I don't know how to produce the buffer being
discussed 😅 I certainly remember seeing warnings during async
compilation. However, now that I'm looking at *Async-native-compile-
log* the lines have no emojis. I also tried M-x byte-compile some file
with warnings and got *Compile-log* buffer, but it doesn't have them
either. Was it some other "compilation" buffer…?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Mon, 10 Mar 2025 16:55:01 GMT)
Full text and
rfc822 format available.
Message #126 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Cc: rudolf <at> adamkovic.org, rms <at> gnu.org, maurooaranda <at> gmail.com,
> stefankangas <at> gmail.com, 61413 <at> debbugs.gnu.org
> Date: Mon, 10 Mar 2025 12:02:01 +0300
>
> On Sat, 2025-03-08 at 18:05 +0100, Kévin Le Gouguec wrote:
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > > > If you want me to install some patches, please post them.
> > > >
> > > > Thanks for the nudge; re-attaching the patch that makes button.el
> > > > preserve help-echo strings; reviewed by Mauro in two parts¹²,
> > > > then
> > > > squashed³. I can install it if we think that fix is
> > > > unambiguously good.
> > >
> > > LGTM, thanks.
> >
> > Just pushed, thanks for the review.
> >
> > I'll defer to other participants regarding what should be done next -
> > e.g. (a) should ⛔ be given a second chance now that it has a help-
> > echo
> > string, making its function more discoverable; (b) should we use
> > another
> > symbol; (c) should we eschew images entirely for that function & use
> > a
> > text button.
>
> Sorry for stupid question, but… I just wanted to see how do warnings
> look now, and I figured I don't know how to produce the buffer being
> discussed 😅
Like this:
M-: (display-warning 'warning "foo") RTE
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Mon, 10 Mar 2025 17:00:03 GMT)
Full text and
rfc822 format available.
Message #129 received at 61413 <at> debbugs.gnu.org (full text, mbox):
On Mon, 2025-03-10 at 18:53 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > Cc: rudolf <at> adamkovic.org, rms <at> gnu.org, maurooaranda <at> gmail.com,
> > stefankangas <at> gmail.com, 61413 <at> debbugs.gnu.org
> > Date: Mon, 10 Mar 2025 12:02:01 +0300
> >
> > On Sat, 2025-03-08 at 18:05 +0100, Kévin Le Gouguec wrote:
> > > Eli Zaretskii <eliz <at> gnu.org> writes:
> > >
> > > > > > If you want me to install some patches, please post them.
> > > > >
> > > > > Thanks for the nudge; re-attaching the patch that makes
> > > > > button.el
> > > > > preserve help-echo strings; reviewed by Mauro in two parts¹²,
> > > > > then
> > > > > squashed³. I can install it if we think that fix is
> > > > > unambiguously good.
> > > >
> > > > LGTM, thanks.
> > >
> > > Just pushed, thanks for the review.
> > >
> > > I'll defer to other participants regarding what should be done
> > > next -
> > > e.g. (a) should ⛔ be given a second chance now that it has a
> > > help-
> > > echo
> > > string, making its function more discoverable; (b) should we use
> > > another
> > > symbol; (c) should we eschew images entirely for that function &
> > > use
> > > a
> > > text button.
> >
> > Sorry for stupid question, but… I just wanted to see how do
> > warnings
> > look now, and I figured I don't know how to produce the buffer
> > being
> > discussed 😅
>
> Like this:
>
> M-: (display-warning 'warning "foo") RTE
Thanks! So, I'm looking at the buffer, and I don't see much difference
compared to how it was before, so my vote in preference of either
applying the patch (that one that started the discussion) or making the
icon a button with text instead still stands.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Mon, 10 Mar 2025 17:47:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
> On Mon, 2025-03-10 at 18:53 +0200, Eli Zaretskii wrote:
>> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
>> > Cc: rudolf <at> adamkovic.org, rms <at> gnu.org, maurooaranda <at> gmail.com,
>> > stefankangas <at> gmail.com, 61413 <at> debbugs.gnu.org
>> > Date: Mon, 10 Mar 2025 12:02:01 +0300
>> >
>> > On Sat, 2025-03-08 at 18:05 +0100, Kévin Le Gouguec wrote:
>> > > Eli Zaretskii <eliz <at> gnu.org> writes:
>> > >
>> > > > > > If you want me to install some patches, please post them.
>> > > > >
>> > > > > Thanks for the nudge; re-attaching the patch that makes button.el
>> > > > > preserve help-echo strings; reviewed by Mauro in two parts¹², then
>> > > > > squashed³. I can install it if we think that fix is unambiguously good.
>> > > >
>> > > > LGTM, thanks.
>> > >
>> > > Just pushed, thanks for the review.
>> > >
>> > > I'll defer to other participants regarding what should be done next -
>> > > e.g. (a) should ⛔ be given a second chance now that it has a help-echo
>> > > string, making its function more discoverable; (b) should we use another
>> > > symbol; (c) should we eschew images entirely for that function & use a
>> > > text button.
>> >
>> > Sorry for stupid question, but… I just wanted to see how do warnings
>> > look now, and I figured I don't know how to produce the buffer being
>> > discussed 😅
>>
>> Like this:
>>
>> M-: (display-warning 'warning "foo") RTE
>
> Thanks! So, I'm looking at the buffer, and I don't see much difference
> compared to how it was before,
Right, the only changes that were committed at this stage impact the
help-echo string, so the only visible difference happens if you hover
over the no-entry sign, or invoke 'C-h .' with point on the sign.
> so my vote in preference of either
> applying the patch (that one that started the discussion) or making the
> icon a button with text instead still stands.
ACK; FWIW I sent a patch combining both suggestions (using a warning
sign - with either an SVG image or an emoji; using a text button for
suppression) on this message:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
Screenshot:
<https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;bug=61413;filename=Screenshot_20250223_163540.png;msg=108>
No strong feelings about it myself though, so feel free to iterate on it
or dismiss it entirely.
(Two things I dislike about that patch:
1. the redundancy between the warning sign & the "Warning" text that
comes after - feels like there is room for improvement, but would
require delving into some warning-prefix-function plumbing I avoided up
to this point;
2. see the FIXME; not sure why warnings.el invokes 'newline' instead of
inserting "\n"; that has undesirable side-effects when placing a button
at the end of the line)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Mon, 10 Mar 2025 18:00:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 61413 <at> debbugs.gnu.org (full text, mbox):
On Mon, 2025-03-10 at 18:46 +0100, Kévin Le Gouguec wrote:
> Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
>
> > On Mon, 2025-03-10 at 18:53 +0200, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > > > Cc: rudolf <at> adamkovic.org, rms <at> gnu.org, maurooaranda <at> gmail.com,
> > > > stefankangas <at> gmail.com, 61413 <at> debbugs.gnu.org
> > > > Date: Mon, 10 Mar 2025 12:02:01 +0300
> > > >
> > > > On Sat, 2025-03-08 at 18:05 +0100, Kévin Le Gouguec wrote:
> > > > > Eli Zaretskii <eliz <at> gnu.org> writes:
> > > > >
> > > > > > > > If you want me to install some patches, please post
> > > > > > > > them.
> > > > > > >
> > > > > > > Thanks for the nudge; re-attaching the patch that makes
> > > > > > > button.el
> > > > > > > preserve help-echo strings; reviewed by Mauro in two
> > > > > > > parts¹², then
> > > > > > > squashed³. I can install it if we think that fix is
> > > > > > > unambiguously good.
> > > > > >
> > > > > > LGTM, thanks.
> > > > >
> > > > > Just pushed, thanks for the review.
> > > > >
> > > > > I'll defer to other participants regarding what should be
> > > > > done next -
> > > > > e.g. (a) should ⛔ be given a second chance now that it has a
> > > > > help-echo
> > > > > string, making its function more discoverable; (b) should we
> > > > > use another
> > > > > symbol; (c) should we eschew images entirely for that
> > > > > function & use a
> > > > > text button.
> > > >
> > > > Sorry for stupid question, but… I just wanted to see how do
> > > > warnings
> > > > look now, and I figured I don't know how to produce the buffer
> > > > being
> > > > discussed 😅
> > >
> > > Like this:
> > >
> > > M-: (display-warning 'warning "foo") RTE
> >
> > Thanks! So, I'm looking at the buffer, and I don't see much
> > difference
> > compared to how it was before,
>
> Right, the only changes that were committed at this stage impact the
> help-echo string, so the only visible difference happens if you hover
> over the no-entry sign, or invoke 'C-h .' with point on the sign.
>
> > so my vote in preference of either
> > applying the patch (that one that started the discussion) or making
> > the
> > icon a button with text instead still stands.
>
> ACK; FWIW I sent a patch combining both suggestions (using a warning
> sign - with either an SVG image or an emoji; using a text button for
> suppression) on this message:
>
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
>
> Screenshot:
>
> <
> https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;bug=61413;filename=Scr
> eenshot_20250223_163540.png;msg=108>
Looks nice! FTR, I'm looking at screenshot, and I think maybe it's
worth clarifying what I mean while saying making the icon a button. I
meant the visual appearance of a button, like the ones you can see in
customization menu for variables. Let me put it another way: if you
take your screenshot to a user who knows nothing about this buffer and
ask them "find all buttons on the screenshot" — do you think they'd
point at the warning sign and say "…and these are obviously buttons
too"? I bet they would not.
Other than that, your solution looks good; and disregarding the button
discussion it already looks better than what's currently on master.
> (Two things I dislike about that patch:
>
> 1. the redundancy between the warning sign & the "Warning" text that
> comes after - feels like there is room for improvement, but would
> require delving into some warning-prefix-function plumbing I avoided
> up
> to this point;
"Better is the enemy of good" 😊 You're making a good point, but this
problem exists disregarding if your patch applied, and so fine to be
fixed separately. I would have made such change a separate patch
anyway, because to me it would seem an unrelated functional change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Mon, 10 Mar 2025 21:57:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
>> > > Like this:
>> > >
>> > > M-: (display-warning 'warning "foo") RTE
>> >
>> > Thanks! So, I'm looking at the buffer, and I don't see much difference
>> > compared to how it was before,
>>
>> Right, the only changes that were committed at this stage impact the
>> help-echo string, so the only visible difference happens if you hover
>> over the no-entry sign, or invoke 'C-h .' with point on the sign.
>>
>> > so my vote in preference of either
>> > applying the patch (that one that started the discussion) or making
>> > the icon a button with text instead still stands.
>>
>> ACK; FWIW I sent a patch combining both suggestions (using a warning
>> sign - with either an SVG image or an emoji; using a text button for
>> suppression) on this message:
>>
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
>>
>> Screenshot:
>>
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;bug=61413;filename=Screenshot_20250223_163540.png;msg=108>
>
> Looks nice! FTR, I'm looking at screenshot, and I think maybe it's
> worth clarifying what I mean while saying making the icon a button. I
> meant the visual appearance of a button, like the ones you can see in
> customization menu for variables. Let me put it another way: if you
> take your screenshot to a user who knows nothing about this buffer and
> ask them "find all buttons on the screenshot" — do you think they'd
> point at the warning sign and say "…and these are obviously buttons
> too"? I bet they would not.
I should have clarified: this patch does *three* things:
1. it adds the "(suppress)" text button,
2. it swaps the no-entry sign with a warning sign,
3. (!) it un-buttonizes the warning sign.
IOW with that patch, the warning signs _are_ purely decorative; the text
buttons really _are_ the only actionable buttons in that screenshot.
ISTM if we go for both 1 & 2 (which both had support among participants,
AFAIR), then 3 is a logical next step: why overload the warning sign
with a suppression function, when there is a perfectly explicit text
button for that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Tue, 11 Mar 2025 06:05:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 61413 <at> debbugs.gnu.org (full text, mbox):
On Mon, 2025-03-10 at 22:56 +0100, Kévin Le Gouguec wrote:
> Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
>
> > > > > Like this:
> > > > >
> > > > > M-: (display-warning 'warning "foo") RTE
> > > >
> > > > Thanks! So, I'm looking at the buffer, and I don't see much
> > > > difference
> > > > compared to how it was before,
> > >
> > > Right, the only changes that were committed at this stage impact
> > > the
> > > help-echo string, so the only visible difference happens if you
> > > hover
> > > over the no-entry sign, or invoke 'C-h .' with point on the sign.
> > >
> > > > so my vote in preference of
> > > > either
> > > > applying the patch (that one that started the discussion) or
> > > > making
> > > > the icon a button with text instead still stands.
> > >
> > > ACK; FWIW I sent a patch combining both suggestions (using a
> > > warning
> > > sign - with either an SVG image or an emoji; using a text button
> > > for
> > > suppression) on this message:
> > >
> > > <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
> > >
> > > Screenshot:
> > >
> > > <
> > > https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;bug=61413;filename
> > > =Screenshot_20250223_163540.png;msg=108>
> >
> > Looks nice! FTR, I'm looking at screenshot, and I think maybe it's
> > worth clarifying what I mean while saying making the icon a button.
> > I
> > meant the visual appearance of a button, like the ones you can see
> > in
> > customization menu for variables. Let me put it another way: if you
> > take your screenshot to a user who knows nothing about this buffer
> > and
> > ask them "find all buttons on the screenshot" — do you think they'd
> > point at the warning sign and say "…and these are obviously buttons
> > too"? I bet they would not.
>
> I should have clarified: this patch does *three* things:
>
> 1. it adds the "(suppress)" text button,
> 2. it swaps the no-entry sign with a warning sign,
> 3. (!) it un-buttonizes the warning sign.
>
> IOW with that patch, the warning signs _are_ purely decorative; the
> text
> buttons really _are_ the only actionable buttons in that screenshot.
>
> ISTM if we go for both 1 & 2 (which both had support among
> participants,
> AFAIR), then 3 is a logical next step: why overload the warning sign
> with a suppression function, when there is a perfectly explicit text
> button for that?
Oh, I see. Well, good idea, but why does (suppress) text on your
screenshot looks like a link and not a button then?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Tue, 11 Mar 2025 21:25:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
>> > > <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
>> > >
>> > > Screenshot:
>> > >
>> > > <https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;bug=61413;filename=Screenshot_20250223_163540.png;msg=108>
>> >
>> > Looks nice! FTR, I'm looking at screenshot, and I think maybe it's
>> > worth clarifying what I mean while saying making the icon a button. I
>> > meant the visual appearance of a button, like the ones you can see in
>> > customization menu for variables. Let me put it another way: if you
>> > take your screenshot to a user who knows nothing about this buffer and
>> > ask them "find all buttons on the screenshot" — do you think they'd
>> > point at the warning sign and say "…and these are obviously buttons
>> > too"? I bet they would not.
>>
>> I should have clarified: this patch does *three* things:
>>
>> 1. it adds the "(suppress)" text button,
>> 2. it swaps the no-entry sign with a warning sign,
>> 3. (!) it un-buttonizes the warning sign.
>>
>> IOW with that patch, the warning signs _are_ purely decorative; the
>> text
>> buttons really _are_ the only actionable buttons in that screenshot.
>>
>> ISTM if we go for both 1 & 2 (which both had support among participants,
>> AFAIR), then 3 is a logical next step: why overload the warning sign
>> with a suppression function, when there is a perfectly explicit text
>> button for that?
>
> Oh, I see. Well, good idea, but why does (suppress) text on your
> screenshot looks like a link and not a button then?
The patch uses the 'buttonize' function, which applies the 'button'
face; which indeed by default looks like a link:
(defface button '((t :inherit link))
"Default face used for buttons."
:group 'basic-faces)
So even though it looks like a link, "(suppress)" should look consistent
with other "clickable things" in Emacs.
As you noticed though, the Custom menus use a different face for their
"clickable things" - 'custom-button', which looks less like a link and
more like regular "boxed gray-background push-buttons".
ISTM using the "regular" 'button' face is better for consistency, unless
we have strong reasons to deviate; I'd rather let users & themes opt in
to aligning 'button' with 'custom-button' if they want (I do that FWIW)
instead of shunning the "canonical" button face because it doesn't look
"buttony enough" by default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Tue, 11 Mar 2025 21:41:01 GMT)
Full text and
rfc822 format available.
Message #147 received at 61413 <at> debbugs.gnu.org (full text, mbox):
On Tue, 2025-03-11 at 22:24 +0100, Kévin Le Gouguec wrote:
> Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
>
> > > > > <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61413#108>
> > > > >
> > > > > Screenshot:
> > > > >
> > > > > <
> > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;bug=61413;file
> > > > > name=Screenshot_20250223_163540.png;msg=108>
> > > >
> > > > Looks nice! FTR, I'm looking at screenshot, and I think maybe
> > > > it's
> > > > worth clarifying what I mean while saying making the icon a
> > > > button. I
> > > > meant the visual appearance of a button, like the ones you can
> > > > see in
> > > > customization menu for variables. Let me put it another way: if
> > > > you
> > > > take your screenshot to a user who knows nothing about this
> > > > buffer and
> > > > ask them "find all buttons on the screenshot" — do you think
> > > > they'd
> > > > point at the warning sign and say "…and these are obviously
> > > > buttons
> > > > too"? I bet they would not.
> > >
> > > I should have clarified: this patch does *three* things:
> > >
> > > 1. it adds the "(suppress)" text button,
> > > 2. it swaps the no-entry sign with a warning sign,
> > > 3. (!) it un-buttonizes the warning sign.
> > >
> > > IOW with that patch, the warning signs _are_ purely decorative;
> > > the
> > > text
> > > buttons really _are_ the only actionable buttons in that
> > > screenshot.
> > >
> > > ISTM if we go for both 1 & 2 (which both had support among
> > > participants,
> > > AFAIR), then 3 is a logical next step: why overload the warning
> > > sign
> > > with a suppression function, when there is a perfectly explicit
> > > text
> > > button for that?
> >
> > Oh, I see. Well, good idea, but why does (suppress) text on your
> > screenshot looks like a link and not a button then?
>
> The patch uses the 'buttonize' function, which applies the 'button'
> face; which indeed by default looks like a link:
>
> (defface button '((t :inherit link))
> "Default face used for buttons."
> :group 'basic-faces)
>
> So even though it looks like a link, "(suppress)" should look
> consistent
> with other "clickable things" in Emacs.
>
> As you noticed though, the Custom menus use a different face for
> their
> "clickable things" - 'custom-button', which looks less like a link
> and
> more like regular "boxed gray-background push-buttons".
>
> ISTM using the "regular" 'button' face is better for consistency,
> unless
> we have strong reasons to deviate; I'd rather let users & themes opt
> in
> to aligning 'button' with 'custom-button' if they want (I do that
> FWIW)
> instead of shunning the "canonical" button face because it doesn't
> look
> "buttony enough" by default.
So… I am not quite sure what consistency you refer to, but I'd presume
it's about, for example, links in *Help* buffer having a `foo-button`
category. Well, the "buttons" there don't actually do any action, they
are actually links. The "-button" prefix I think was given them by
mistake.
The fact button face inherits from 'link is a surprise to me and seems
wrong… But such discussion would result in another hundred emails, so
let's stick to the question of "suppress button" face 😅
Unlike buttons/links on the *Help* page, the "suppress" button doesn't
move you to some other buffer, instead it applies action (adds
suppression). Examples of buttons that do action may be seen in
customization menu, and they actually look like buttons. So as far as
consistency goes, making "suppress" button look like a button seems
fine to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Fri, 18 Apr 2025 07:14:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Hello,
In a discussion on emacs-devel I suggested moving the warning icon,
whatever it is to be, to the end of the warning. I think a lot of users
will be more likely to see it as a button they can click, in that case.
The problem with having it at the beginning, especially when multiple
warnings are displayed, is that it looks like a bullet point, albeit an
eccentric choice of bullet point.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Fri, 18 Apr 2025 11:20:04 GMT)
Full text and
rfc822 format available.
Message #153 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Fri, 18 Apr 2025 15:13:12 +0800
>
> Hello,
>
> In a discussion on emacs-devel I suggested moving the warning icon,
> whatever it is to be, to the end of the warning.
To the end is wrong, as it could become invisible due to
line-truncation etc. Maybe to the new line after the warning?
(And let me say up front that no matter what we do, someone is bound
to come back complaining. So my personal recommendation is to leave
this alone and let users get used to this, even if it will take some
more moons. We have bigger fish to fry, anyway.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Fri, 18 Apr 2025 16:18:03 GMT)
Full text and
rfc822 format available.
Message #156 received at 61413 <at> debbugs.gnu.org (full text, mbox):
>> In a discussion on emacs-devel I suggested moving the warning icon,
>> whatever it is to be, to the end of the warning.
>
> To the end is wrong, as it could become invisible due to
> line-truncation etc. Maybe to the new line after the warning?
The best proposal I have seen in this discussion that conforms
to most Emacs UI guidelines is this:
⚠️ Warning Warning Warning Warning Warning [Disable]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 19 Apr 2025 01:04:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 18 Apr 2025 at 02:18pm +03, Eli Zaretskii wrote:
> To the end is wrong, as it could become invisible due to
> line-truncation etc. Maybe to the new line after the warning?
Perhaps after the word "Warning". It's just column zero that makes it
seem like a bullet point, to me.
> (And let me say up front that no matter what we do, someone is bound
> to come back complaining. So my personal recommendation is to leave
> this alone and let users get used to this, even if it will take some
> more moons. We have bigger fish to fry, anyway.)
Regardless of the particular bug, I think that displaying warnings
ergonomically affects users more than it first seems to us as
developers.
Whenever Emacs's warnings behaviour changes, Debian gets a flurry of bug
reports. Even just warnings from Emacs running in batch mode during apt
installations, i.e. among piles of other terminal output, on the
as-yet-unreleased Debian version 13, got us four identical bug
reports.[1]
[1] https://bugs.debian.org/1099506 (cf. "Merged with ...")
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 19 Apr 2025 07:38:03 GMT)
Full text and
rfc822 format available.
Message #162 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 61413 <at> debbugs.gnu.org
> Date: Sat, 19 Apr 2025 09:03:24 +0800
>
> On Fri 18 Apr 2025 at 02:18pm +03, Eli Zaretskii wrote:
>
> > (And let me say up front that no matter what we do, someone is bound
> > to come back complaining. So my personal recommendation is to leave
> > this alone and let users get used to this, even if it will take some
> > more moons. We have bigger fish to fry, anyway.)
>
> Regardless of the particular bug, I think that displaying warnings
> ergonomically affects users more than it first seems to us as
> developers.
>
> Whenever Emacs's warnings behaviour changes, Debian gets a flurry of bug
> reports. Even just warnings from Emacs running in batch mode during apt
> installations, i.e. among piles of other terminal output, on the
> as-yet-unreleased Debian version 13, got us four identical bug
> reports.[1]
My point is that if we keep changing this evidently confusing stuff,
we don't let users get used to it. Keeping it unchanged will allow
them to get used, event if it takes time. Changes are good if we have
a clear winner: something that could never cause any confusion nor
arguments as to what it means and how to use it. This is not that
case, AFAICT. When choosing from a set of similarly confusing
choices, it is best not to make any change, letting users adapt.
I see no reason for a panic given the bug reports. Just patiently
explain what this means, and be done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 19 Apr 2025 10:04:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 61413 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 19 Apr 2025 at 10:36am +03, Eli Zaretskii wrote:
> My point is that if we keep changing this evidently confusing stuff,
> we don't let users get used to it.
Yes, sure. I agree. I just want to defend the idea that things like
this are fish worth frying.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#61413; Package
emacs.
(Sat, 19 Apr 2025 11:58:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 61413 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 61413 <at> debbugs.gnu.org
> Date: Sat, 19 Apr 2025 18:03:16 +0800
>
> Hello,
>
> On Sat 19 Apr 2025 at 10:36am +03, Eli Zaretskii wrote:
>
> > My point is that if we keep changing this evidently confusing stuff,
> > we don't let users get used to it.
>
> Yes, sure. I agree. I just want to defend the idea that things like
> this are fish worth frying.
As long as my point is taken, and you-all still think we should change
this, I won't fight.
This bug report was last modified 55 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.