GNU bug report logs - #63811
29.0.91; todo-mode item editing bugs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63811 in the body.
You can then email your comments to 63811 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.91; todo-mode item editing bugs
Date: Wed, 31 May 2023 11:12:32 +0200

[Message part 1 (text/plain, inline)]

I have encountered several bugs in todo-mode when creating and editing
todo items.  I have fixes for them and since I'm the todo-mode
maintainer I intend to push them to the Savannah repo when I get a bug
number and clearance for which branch to push to.  The bugs are
long-standing, at least since Emacs 28 and probably earlier.  The fixes
touch no code outside of todo-mode.el and seem low-risk; in my testing
they work as expected.  I've attached a diff against emacs-29 below (the
todo-mode.el files in current emacs-29 and master are identical).

One of the bugs is that, when editing an item's date-time header string,
which uses replace-match, the match data can get clobbered, e.g. by
using dabbrev-expand while editing.  (In bug#42976 I had fixed the same
bug just for editing a done item comment, but at the time didn't notice
that it can also happen when editing the item header string.)

The other bugs all have to do with the fact that you can switch from the
buffer in which an item is entered or edited (mainly the minibuffer, but
for editing also a special indirect buffer of the todo-mode buffer) to
the todo-mode buffer and there, move point to another item (with `n' or
`p') or to another todo category in the todo file (with `f' or `b').
This possibility is useful in order, for example, to copy text from
another item to use in the item you are creating or editing (you could,
of course, do that before invoking the item insertion or editing
command, then there's no problem).  But when you move point in this way
and then switch back to the editing buffer without moving point back to
where it was when you invoked the item insertion or editing command,
this can cause problems ranging from relatively harmless though
annoying, such as misplacement of the inserted or edited item (you can
always relocate the item later in todo-mode, when you notice the
misplacement), to serious, such as unintentionally replacing data and
even corruption of the todo-mode file format.

The latter can happen in three ways:
(1) Type `ee' on an item in todo-mode to edit it in the minibuffer and
before typing RET to complete the edit, switch back to the todo-mode
buffer, type `f' to display the next category in the todo file, then
switch back to the minibuffer and complete the edit.  The edited item
does not replace the item on which `ee' was invoked but instead is
entered into the category moved to as the first item, replacing the item
that was there before.
(2) In a todo category that has done items, type `ih' ("insert here") to
insert a new item into the todo buffer on the line at point, and before
completing the item (by typing RET in the minibuffer), switch to the
todo-mode buffer, display the done items (`v'), move point (e.g. with
`n') to one of the done items, then switch back to the minibuffer and
complete with RET.  The item will be inserted in the done items section
but it doesn't have the form of a done item, so you can't repair the
mistake using todo-mode commands, and also the calculated category
counts of todo and done items now conflict with the resulting
distribution of the items in the category.
(3) The todo-mode buffer is read-only most of the time and is supposed
to be changed only by using todo-mode commands, which temporarily make
it writeable.  However, the item editing commands `ee' (for item text)
and `ec' (for done item comments) currently already make the todo-mode
buffer writeable when the minibuffer is being used for editing, and if
you then switch to the todo-mode buffer, you can corrupt it by inserting
newlines or yanking arbitrary text (but self-inserting keys remain
disabled in todo-mode).


In GNU Emacs 29.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.37, cairo version 1.17.6) of 2023-05-27 built on strobelfssd
Repository revision: 5e7c826bfa5cb7459f5b162b498af1c57c4578e6
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Linux From Scratch r11.3-100-systemd

Configured using:
 'configure -C --with-xwidgets 'CFLAGS=-Og -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM XWIDGETS GTK3 ZLIB

[Message part 2 (text/plain, inline)]

2023-05-31  Stephen Berman  <stephen.berman <at> gmx.net>

	Fix several todo-mode.el item editing bugs (bug#)

	* lisp/calendar/todo-mode.el (todo-insert-item--basic): With
	insertion type 'here', ensure item is inserted on the todo-mode
	line where the command was invoked.
	(todo-edit-item--cat, todo-edit-item--pos): New variables.
	(todo-edit-item--text): Restrict the scope of nil-valued
	buffer-read-only to the functions that change buffer text.  If
	user moved point while editing a single-line todo item or a done
	item comment, or while inserting a done item comment, restore
	point, and for comments, make sure the done items section is
	displayed.  For multiline items, set the new variables so
	todo-edit-quit can use them.
	(todo-edit-quit): Use the values of the new variables to restore
	point in the todo-mode buffer if it had been moved while editing.
	(todo-edit-item--header): Avoid clobbering match data when editing
	a todo item header.

[Message part 3 (text/x-patch, attachment)]

Message #8 received at 63811 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 63811 <at> debbugs.gnu.org
Subject: Re: bug#63811: 29.0.91; todo-mode item editing bugs
Date: Wed, 31 May 2023 15:31:07 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Wed, 31 May 2023 11:12:32 +0200
> 
> I have encountered several bugs in todo-mode when creating and editing
> todo items.  I have fixes for them and since I'm the todo-mode
> maintainer I intend to push them to the Savannah repo when I get a bug
> number and clearance for which branch to push to.  The bugs are
> long-standing, at least since Emacs 28 and probably earlier.  The fixes
> touch no code outside of todo-mode.el and seem low-risk; in my testing
> they work as expected.  I've attached a diff against emacs-29 below (the
> todo-mode.el files in current emacs-29 and master are identical).

Assuming all the tests still pass after these changes, please go ahead
and install on emacs-29, and thanks.

Message #13 received at 63811-done <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63811-done <at> debbugs.gnu.org
Subject: Re: bug#63811: 29.0.91; todo-mode item editing bugs
Date: Wed, 31 May 2023 16:25:14 +0200

On Wed, 31 May 2023 15:31:07 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Wed, 31 May 2023 11:12:32 +0200
>>
>> I have encountered several bugs in todo-mode when creating and editing
>> todo items.  I have fixes for them and since I'm the todo-mode
>> maintainer I intend to push them to the Savannah repo when I get a bug
>> number and clearance for which branch to push to.  The bugs are
>> long-standing, at least since Emacs 28 and probably earlier.  The fixes
>> touch no code outside of todo-mode.el and seem low-risk; in my testing
>> they work as expected.  I've attached a diff against emacs-29 below (the
>> todo-mode.el files in current emacs-29 and master are identical).
>
> Assuming all the tests still pass after these changes, please go ahead
> and install on emacs-29, and thanks.

All todo-mode tests passed `make check'.  I did get some unexpected
failures in a few other tests and a hang in epg-tests, but the same
thing happened when I ran `make check' on my master branch, which does
not have the todo-mode changes, so these are not responsible for the
test problems, and I went ahead and pushed the changes to emacs-29 and
am closing the bug report.  Thanks.

Steve Berman

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.