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

[Stephen Berman]

On Sun, 08 Sep 2013 23:07:16 +0200 Stephen Berman <stephen.berman@gmx.net> 
wrote:

> On Fri, 30 Aug 2013 23:48:28 +0530 Kanthimathi R <rkanthimathi@hotmail.co.in> 
> 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