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

Previous Next

Package: emacs;

Reported by: Kanthimathi R <rkanthimathi <at> hotmail.co.in>

Date: Fri, 30 Aug 2013 18:17:01 UTC

Severity: minor

Found in version 24.3.50

Full log


View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 15225 <at> debbugs.gnu.org
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
Date: Fri, 20 Dec 2013 18:44:52 +0100
On Sun, 08 Sep 2013 23:07:16 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Fri, 30 Aug 2013 23:48:28 +0530 Kanthimathi R <rkanthimathi <at> 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




This bug report was last modified 11 years and 177 days ago.

Previous Next


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