Subject: Re: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions

From: Stephen Berman <[email-masked]>
Date: Fri, 20 Dec 2013 18:44:52 +0100

On Sun, 08 Sep 2013 23:07:16 +0200 Stephen Berman <[email-masked]> wrote:

> On Fri, 30 Aug 2013 23:48:28 +0530 Kanthimathi R <[email-masked]> wrote:

>> --==-- todo-mode
>> [Aug 29, 2013] `C m' MUST create new files on demand
>> 	
>> 	1. Visit the odt category.
>> 	2. Type `C m' on the first entry
>> 	3. When prompted for a file-name, give a non-existing file name.
>> 	4. Note that completion insists on a MUST-MATCH.
>> 	5. I was expecting that the new file will be created and the entry
>> moved to that category.
>
> I guess this is a reasonable expectation.  My use-case for `C m' is that
> I have a main todo file containing unrelated categories I add as the
> need arises, and I have more specific todo files, and occasionally I
> find that a category in the main file fits in better with one of the
> more specific files, so I move it to that.  So my assumption was that
> users would only want to move categories between existing files.  But I
> guess it makes sense to be able to create the file on moving the
> category and I'll make that change.

I've now implemented this.  But actually, I think you really meant the
command todo-move-item (bound to `m') instead of todo-move-category (`C
m').  That one is trickier, because it uses todo-category-completions,
which a number of other commands also use.  I'm not sure such a change
is good for the other commands, and I think it's not such a
straightforward change, so I've refrained from implementing it for the
time being.  But I'll give it more consideration.

>> [Aug 28, 2013]  `i i' should append or prepend items by default
>> 	
>> 	GTD says separate out collection and processing.
>> 	
>> 	Insertion of an item is a "collection" activity.  Setting a
>> 	priority is a "processing" activity.  So I recommend that `i i' add
>> 	an item to the top or the bottom of the file.  Let the user move
>> 	the raise or lower the items at a later point in time during the
>> 	"processing" phase.
>
> I'm reluctant to eliminate prioritization from `i i' (and hence from
> most of the other item insertion commands).  This has always been a
> feature of todo-mode.el, implicit in the command's name, as the manual
> points out: insertion does not entail appending or prepending.  But I
> guess it's reasonable to have an option for prioritized item insertion
> to make typing RET on being prompted for a priority default to first or
> last item.

I've implemented the default priority option.

>> [Aug 30, 2013] When I `C m', most often I want to stay in the same category
>> 	
>> 	The current behaviour is to move to the new category.  I
>> 	essentially need a pop or a prefix binding.
>
> Making this possible with a prefix argument seems like a good idea.

I've also put this on hold, because it also has implications for other
commands and I need to think about it more.

>> --==-- todo-mode/bugs
>> [Aug 29, 2013] With desktop mode on and todo-mode leaves a stacktrace
>> 	
>> 	Strip your .emacs as below.
>> 	
>> 	 (custom-set-variables
>> 	  ;; custom-set-variables was added by Custom.
>> 	  ;; If you edit it by hand, you could mess it up, so be careful.
>> 	  ;; Your init file should contain only one such instance.
>> 	  ;; If there is more than one, they won't work right.
>> 	  '(calendar-view-diary-initially-flag t)
>> 	  '(desktop-base-file-name ".emacs-desktop.junk")
>> 	  '(desktop-path (quote ("~")))
>> 	  '(desktop-save-mode t)
>> 	  '(diary-file "~/.emacs.d/todo/emacs.todo")
>> 	  '(diary-number-of-entries 30)
>> 	  '(savehist-mode t)
>> 	  '(todo-wrap-lines t))	
>> 	
>> 	emacs
>> 	M-x todo-show
>> 	Make sure that todo buffer shows up fine
>> 	C-x C-c and save the desktop file
>> 	
>> 	Re-load emacs
>> 	M-x toggle-debug-on-error	
>> 	M-x todo-show
>> 	
>> 	See following stacktrace.	
>> 	
>> 	Debugger entered--Lisp error: (error "Category nil is missing todo-category-done string")
>>   signal(error ("Category nil is missing todo-category-done string"))
>>   error("Category %s is missing todo-category-done string" nil)
>>   todo-category-select()
>>   todo-show(nil 1)
>>   call-interactively(todo-show record nil)
>>   command-execute(todo-show record)
>>   execute-extended-command(nil "todo-show")
>>   call-interactively(execute-extended-command nil nil)
>>   command-execute(execute-extended-command)
>
> This error actually has nothing to do with desktop: you also get it with
> this recipe:
> 1. emacs -Q 
> 2. C-x C-f ~/.emacs.d/todo/emacs.todo RET
> 3. M-x todo-show
> After step 2, the file emacs.todo is in fundamental mode (because, as
> you note below, todo-mode is not yet loaded), but when todo-show finds
> that a buffer is already visiting the file, it doesn't check the mode,
> assuming it is already in todo-mode, and this leads to the error.  This
> can be avoided by making todo-show check the mode and call todo-mode if
> the buffer isn't already in it; however, automatically putting files
> whose names end in ".todo" into todo-mode, as you suggest below, would
> also avoid the error and be a more general solution.
>
> There is, however, another problem that shows up with a saved desktop
> containing a buffer visiting a todo file: namely, although the restored
> buffer is in todo-mode (that is, after fixing the above error), it is
> not properly displayed with narrowing to the current category.  I think
> I can fix this by writing a function to add to
> desktop-buffer-mode-handlers

I've now implemented this.

>> [Aug 28, 2013] Highlighting reports an error
>> 	
>> 	F H on an item results in
>> 	
>> 	  call-interactively: Symbol's value as variable is void: hl-line-mode
>
> Shortly before installing the package into trunk I had wrapped require
> inside eval-when-compile to silence the byte compiler and must have
> neglected to test it.  I should have used eval-and-compile and will
> change it accordingly.

This is also done.

>> [Aug 29, 2013] todo-mode not recognized with emacs -Q
>> 	
>> 	1. emacs -Q
>> 	2. C-x C-f ~/.emacs.d/todo/emacs.todo
>> 	3. The file is not visited in todo mode and hence not fontified.
>> 	
>> 	I think `auto-mode-alist' should have an entry for todo-mode /even if/
>> todo-mode is not loaded apriori.
>
> It's a good idea to make todo files recognizable without previously
> loading the package, but it's not necessary to add to the default value
> of auto-mode-alist; I'll follow the practice of many other packages and
> put an autoload cookie before each top-level add-to-list sexp in
> todo-mode.el, and also before the corresponding mode functions (I should
> have done this earlier but wasn't aware of the practice).

This too is done.

>> 	The section that talks about y k c d sequence seems to occur a bit
>> 	too early in the manual.  It should be placed a bit late in the
>> 	manual.  Mentioning the mnemonics upfront, y => diarY k => marK etc
>> 	is *good* though.
>
> Since the item insertion key sequences are a central aspect of editing
> in Todo mode, I think they belong in that chapter of the manual, and
> that chapter shouldn't come too late, since editing (which includes
> adding new items) is one of the most common functions of Todo mode.
> (BTW, Stefan Monnier has proposed a different implementation of todo
> item insertion key sequences that has a nice UI with direct feedback of
> available completions; however, this relies on lexical binding, which
> Todo mode currently can't use, since it makes essential use of some
> dynamically scoped variables from the calendar package.  But he's
> working on transitioning the calendar code to lexically binding, so this
> feature may soon be possible in Todo mode.)

While waiting for Calendar to go lexical, I've implemented a dynamic
binding version of Stefan's proposal, so this will facilitate using item
insertion.

I need to give some of your other recommendations and feature requests
more thought, so they probably will have to wait till the feature freeze
is over.  But I will update the manual before the next release.  In the
mean time I'll leave this bug open.

Steve Berman