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
> Date: Wed, 19 Feb 2025 18:41:38 -0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudolf <at> adamkovic.org, Hi-Angel <at> yandex.ru,
> rms <at> gnu.org, 61413 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
> > Mauro Aranda <maurooaranda <at> gmail.com> 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.
Since 'buttonize' doesn't remove any other text properties, I would be
surprised to hear that some Lisp program used this as a means to
ignore help-echo property of the STRING argument. In any case,
removing that property before calling 'buttonize' should be simple,
no?
> 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.
Yes, and I believe the proposed patch (b) does something very similar?
But I agree that not touching the help-echo is cleaner.
This bug report was last modified 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.