GNU bug report logs -
#63811
29.0.91; todo-mode item editing bugs
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Wed, 31 May 2023 09:13:01 UTC
Severity: normal
Found in version 29.0.91
Done: Stephen Berman <stephen.berman <at> gmx.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#63811: 29.0.91; todo-mode item editing bugs
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 63811 <at> debbugs.gnu.org.
--
63811: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63811
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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
[Message part 3 (message/rfc822, inline)]
[Message part 4 (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 5 (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 6 (text/x-patch, attachment)]
This bug report was last modified 1 year and 355 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.