[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64298: 29.0.92; Fixes for several todo-mode bugs
From: |
Stephen Berman |
Subject: |
bug#64298: 29.0.92; Fixes for several todo-mode bugs |
Date: |
Tue, 27 Jun 2023 14:50:21 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
On Tue, 27 Jun 2023 14:37:33 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 64298@debbugs.gnu.org
>> Date: Tue, 27 Jun 2023 12:02:29 +0200
>>
>> I cannot guarantee that all possibilities are now accounted for, but
>> systematically going through all combinations of commands and the
>> conditions under which they are executed would be very tedious and
>> time-consuming, and I think it's better to include fixes for the known
>> problems in emacs-29 rather than waiting for a possibly more
>> comprehensive fix.
>
> OK.
>
>> One of the two cases, that of moving a todo-mode category from one todo
>> file to another, also revealed a bad UX effect. Moving the category
>> requires applying `widen' (since todo-mode uses narrowing to show only
>> the current category's items), but in the current code the user is
>> prompted for the target file after widening, which makes the file's
>> internal structure visible, which is ugly and unnecessarily confusing.
>> I fixed this with the second attached patch (applied after the first
>> one) by narrowing again before the prompt and later widening again to
>> delete the content of the moved category. This is a straightforward and
>> no-risk fix, so I hope it's also acceptable for emacs-29.
>
> It looks safe, but it is also not very urgent, since this problem
> existed since long ago, right? So how about doing this on master
> instead?
All right.
>> > The 2nd patch is the scariest. How grave is it, and if it's grave,
>> > how come it was not reported until now? In general, I'd prefer to
>> > have the 2nd patch on master, not on the release branch, at least for
>> > now. (We could consider backporting it after Emacs 29.1 is released.)
>>
>> I'm surprised you find this patch scary; what specifically do you think
>> is dangerous about it?
>
> The non-trivial dance with regular expressions, of course.
Due to using todo-item-end instead of todo-forward-item? Well ok, I
can't readily prove your reservations are unwarranted.
>> AFAICT such problems don't lead to data loss and with some effort can be
>> repaired, but they shouldn't happen in the first place, and with the
>> fix, they don't. And I don't think the fix can cause any other
>> problems, at least I haven't seen any in testing it.
>>
>> As for why there has been no previous report of this bug, I guess it's
>> due to a combination of involving a relatively seldom needed command,
>> having triggering conditions that probably also don't occur very often,
>> and above all, there being presumably very few regular users of
>> todo-mode. Admittedly, that combination speaks against the urgency of
>> committing the fix to emacs-29, but again, the problem is, if not grave,
>> at least very confusing, and AFAICT the fix works and is low-risk.
>
> I'd like to release Emacs 29.1 _soon_. The only way to ensure this is
> not to install on emacs-29 anything that doesn't _have_ to be there.
> So please look at this from my vantage point, and try to play "devil's
> advocate" against yourself. Then tell me what you think.
I understand and appreciate your concerns. So I'll push the revised
buffer-read-only fix, the print-{length,level} fix and the two doc fixes
to emacs-29, and install the other two patches in master (after the
emacs-29 fixes have been merged to master). But if someone else does
report bugs against emacs-29 that the those two patches fix, I'll come
back to you about backporting them ;-).
Steve Berman