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: Mauro Aranda <maurooaranda <at> gmail.com>
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
Subject: bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign
Date: Wed, 19 Feb 2025 22:25:07 +0100

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?

Previous Next

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