Subject: bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

From: Mauro Aranda <[email-masked]>
Date: Wed, 19 Feb 2025 18:41:38 -0300

Kévin Le Gouguec <[email-masked]> writes:

 > Mauro Aranda <[email-masked]> writes:
 >
 >>> > ¹ 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 suspect they don't, but of course I can't be sure.  If we don't want
to risk it, then yes, I'd say (c) is the way to go.  I don't like (a)
very much because it's just a workaround.

 > 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?

I was thinking in not overwriting the help-echo property if the
help-echo argument is nil.

Currently, button--properties forces a value for the help-echo property.
So it would be like: If it's nil,  don't add the help-echo property to
the property list at all, leaving a previous help-echo property
untouched.