[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: |
Mauro Aranda |
Subject: |
bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign |
Date: |
Thu, 20 Feb 2025 06:59:44 -0300 |
User-agent: |
Mozilla Thunderbird |
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Wed, 19 Feb 2025 18:41:38 -0300
>> Cc: Eli Zaretskii <eliz@gnu.org>, rudolf@adamkovic.org,
Hi-Angel@yandex.ru,
>> rms@gnu.org, 61413@debbugs.gnu.org, stefankangas@gmail.com
>> From: Mauro Aranda <maurooaranda@gmail.com>
>>
>> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>>
>> > Mauro Aranda <maurooaranda@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?
Agreed.
>> 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?
It does.
> But I agree that not touching the help-echo is cleaner.
OK, so let's wait for Kevin's patch to improve buttonize-region too.
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, (continued)
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Rudolf Adamkovič, 2025/02/22
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Kévin Le Gouguec, 2025/02/19
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Eli Zaretskii, 2025/02/19
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Mauro Aranda, 2025/02/19
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Kévin Le Gouguec, 2025/02/19
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Mauro Aranda, 2025/02/19
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Eli Zaretskii, 2025/02/20
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign,
Mauro Aranda <=
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Kévin Le Gouguec, 2025/02/20
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Mauro Aranda, 2025/02/20
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Kévin Le Gouguec, 2025/02/20
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Mauro Aranda, 2025/02/20
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Kévin Le Gouguec, 2025/02/22
- bug#61413: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign, Kévin Le Gouguec, 2025/02/23