GNU bug report logs - #61413
[PATCH] Make warnings show a "warning" emoji instead of a stop-sign

Previous Next

Full log

View this message in rfc822 format

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: Rudolf Adamkovič <rudolf <at> adamkovic.org>, Robert Pluim <rpluim <at> gmail.com>, rms <at> gnu.org, 61413 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign
Date: Sun, 16 Feb 2025 10:27:59 +0100

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.

Previous Next

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