bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a sto


From: Kévin Le Gouguec
Subject: bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign
Date: Wed, 19 Feb 2025 22:25:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Mauro Aranda <maurooaranda@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]