GNU bug report logs -
#61413
[PATCH] Make warnings show a "warning" emoji instead of a stop-sign
Previous Next
Full log
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.
This bug report was last modified 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.