GNU bug report logs - #42976
28.0.50; todo-mode.el editing bugs

Previous Next

Full log

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: 28.0.50; todo-mode.el editing bugs
Date: Fri, 21 Aug 2020 22:26:09 +0200

I've encountered the following bugs while using todo-mode.el.  These
bugs assume the existence of a todo file, which is created (by default
in ~/.emacs.d/todo/) by the first invocation of the autoloaded function
todo-show.  The first two bugs result from attempting to use the todo
file, which, however, has not yet been read into a buffer.

Bug #1:
0. emacs -Q
1. C-h f tod- TAB C-g
   => This loads todo-mode.el, making commands available that assume a
   current todo file, which just loading the library does not do.  This
   leads to the following errors:
2. M-x todo-insert-item RET i RET bla RET
   => Wrong type argument: number-or-marker-p, nil
3. M-x calendar, in Calendar buffer type `i t RET bla'
   => Category nil is missing todo-category-done string
What should happen in both steps 2 and 3 is that the item "bla" should
be inserted into the first category of the todo file.

Bug #2:
0. emacs -Q
1. C-h f tod- TAB C-g (as above, loads library but not todo file)
2. M-x todo-jump-to-category RET
3. Type the name of a non-exisiting category (existing categories in the
   default todo file are shown by TAB) and then RET
   => In the minibuffer this prompt appears:
   Add new category "bla" to file "nil"? (y or no)
   This is a bug if the todo file has a name other than "nil" (which it
   normally will).  Type `n' to cancel the command.
4. Repeat step 3 but now type `y' at the (buggy) prompt
   => Wrong type argument: stringp, nil
What should happen is that the todo file should be found and its name
used in step 3, and in step 4, the new category "bla" should be added to
the file.

The next two bugs assume a todo file containing a category with at least
one item with a standard diary-format date header consisting of month,
day and year, which can be created in todo-mode by typing `ii'.

Bug #3:
0. emacs -Q
1. M-x todo-show (to visit the todo file with point on the first item of
   the first category).
2. Typing `1edd' increments the day number by 1 (`2edd' increments by 2,
   etc.), adjusting the month and year if necessary, e.g. `1edd' changes
   the date header [Dec 30, 2019] to [Dec 31, 2019], and repeating
   `1edd' changes the date to [Jan 1, 2020].  Typing `1edm' increments
   the month without changing the day number, but should also adjust the
   year, like `1edd' does.  The bug is that the year is not adjusted:
   `1edm' changes [Dec 1, 2019] to [Jan 1, 2019].
3. Likewise, now (with header [Jan 1, 2019]) typing `-1edm' (or `-edm')
   changes the header to [Dec 1, 2019] instead of the expected [Dec 1,
   2018] (in contrast to typing `-31edd', which correctly changes [Jan
   1, 2019] to [Dec 1, 2018]).
In these cases, the year should be adjusted appropriately.

Bug #4:
0. emacs -Q
1. M-x todo-show (as above).
2. The month should be incrementable or decrementable by an arbitrary
   amount, and this works when the numeric prefix is greater than 12,
   but when it is less than -12, odd results often happen (in addition
   to bug #3, the failure of adjustment of the year).  E.g.:
   `-13edm' changes [Jan 1, 2019] to [Dec 1, 2019] (correct month, wrong
   year due to bug #3), but
   `-14edm' fails to change [Jan 1, 2019], and
   `-15edm' changes [Jan 1, 2019] to [Feb 1, 2019]
   and so on.
In these cases the correct month change should be made.

Bug #5:
This bug assumes a todo file containing a category with at least
one done item with a comment, which can be created in todo-mode by
typing `C-u d' with point on a (not-done) todo item: `d' marks the todo
item as done and moves it to a section below the not-done todo items
(which is hidden by default) and the prefix argument prompts to add a
comment to the done item.
0. emacs -Q
1. M-x todo-show
2. Type `v' to show the done items section.
3. Type `n' until point is on a done item with a comment (which appears
   in brackets at the end of the done item, prefixed by "COMMENT:").
4. Type `ec' to edit the comment in the minibuffer.
5. Use dabbrev-expand (M-/) on the comment being edited.
6. Type RET to complete the edit.
   => This raises the error: "replace-match subexpression does not
   exist".  (With this recipe I have also gotten an args-out-of-range
   error, but that currently isn't readily reproducible, unlike the
   replace-match error.)
It should be possible to use dabbrev-expand when editing a done item
comment.


I have fixes for these bugs and I'll commit them to master with a
reference to the number of this bug report.


In GNU Emacs 28.0.50 (build 16, x86_64-pc-linux-gnu, GTK+ Version 3.24.17, cairo version 1.17.3)
 of 2020-08-21 built on strobe-jhalfs
Repository revision: 3e10174fb65f4eb601b1921271bdcf10c933b879
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Linux From Scratch SVN-20200401

Configured using:
 'configure 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

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

Previous Next

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