GNU bug report logs - #77917
31.0.50; [PATCH] Stop using the "stop" sign for all warning levels

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rpluim <at> gmail.com, 77917 <at> debbugs.gnu.org, yantar92 <at> posteo.net, prot <at> protesilaos.com, kevin.legouguec <at> gmail.com
Subject: bug#77917: 31.0.50; [PATCH] Stop using the "stop" sign for all warning levels
Date: Fri, 09 May 2025 09:54:09 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>,
>   rpluim <at> gmail.com,
>   yantar92 <at> posteo.net,  77917 <at> debbugs.gnu.org,  prot <at> protesilaos.com
> Date: Fri, 09 May 2025 09:25:50 +0300
> 
> >> * stop using the "warnings-suppress" icon; keep it for
> >>   backward-compatibility in case there are out-of-tree users,
> >> * insert a new plain "warning" icon (with SVG representation that can
> >>   use the 'warning face),
> >> * add a text button for suppression.
> >
> > How about doing that, but without the icon?
> 
> The icon helps to draw the user's attention to the warning.

We have other, more portable ways of drawing attention.  For example,
use the 'warning' face, or show "!! WARNING !!" instead, or both.

> > The icon is problematic on TTY frames, and why do we need it, when the
> > text already says "Warning: SOMETHING"?
> 
> This is not problematic since 'define-icon' supports many layers.
> >From (info "(elisp) Icons"):
> 
>   If ‘icon-preference’ is ‘(image emoji symbol text)’ (i.e., allowing all of
>   these forms of icons), in this case, ‘icon-string’ will first check that
>   Emacs is able to display images at all, and then whether it has support
>   for each of those different image formats.  If that fails, Emacs will
>   check whether Emacs can display emojis (in the current frame).  If that
>   fails, it'll check whether it can display the symbol in question.  If
>   that fails, it'll use the plain text version.

Our current facilities for determining whether a particular expression
of an icon can be displayed by the frame are somewhat limited.  For
example, char-displayable-p could return non-nil on a GUI frame even
if there's no font that can display a character, and on a TTY frame we
think any character can be displayed if the terminal's encoding is
UTF-8.  That's the reason for the delicate dance with default values
for the 'symbol' choice we have now.

Dropping the icon solves all those problems entirely, and without any
leftovers.

I understand the urge to use the icons, since when it works, the
display is much nicer.  But IMNSHO, the icon machinery we have is not
yet mature enough to use it in such ubiquitous situations, where
user-facing messages need to explain themselves with 110% clarity.
Showing something like "\u25b2Warning: ..." is not my idea of a good
warning UX.  We should try avoiding this at all costs, even if that
means, sadly, dropping the icon.

Or maybe we could come up with something that uses the icon only on
GUI frames.  But even then, we should modify icons.el to use
char-displayable-on-frame-p instead, to avoid false positives.

Previous Next

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