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

[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





reply via email to

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