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

[Stephen Berman <stephen.berman@gmx.net>]

On Sat, 31 Aug 2013 18:09:28 +0530 Jambunathan K <kjambunathan@gmail.com> wrote:

> 1. `e m' on an item
> 2. C-x b
> 3. `e e' on an item
>
> See the following:
>
>     todo-edit-multiline-item: Buffer name `*Todo Edit*' is in use [4
>     times]

This only happens with the above recipe if the item in step 1 is a
multiline item and in step 3 you type `e e' on the same item.  It also
happens if in step 3 you type `e m' instead of `e e', and then it
doesn't matter whether the item is the same.  The reason is because
todo-edit-multiline-item (bound to `e m') uses an indirect buffer (and
todo-edit-item (bound to `e e') calls todo-edit-multiline-item if the
item is multiline), and currently allows only a single instance, named
*Todo Edit*.

> I would expect that it switch to the buffer instead.

This is a reasonable expectation, but I think it's a bit involved to
implement correctly, because you have to keep track of which item from
the Todo mode buffer is associated with which indirect buffer, whose
content may have changed.  I think I can make it work, but is it really
important to you to be able to have multiple item editing buffers?  In
terms of key strokes, there's little difference between `C-x b'+`e m'
and `C-x C-q'+`e m'.  (I understand from your other post that you'd
prefer to edit multiple items in a single buffer, but that's a different
functionality.)

> ----------------------------------------------------------------
>
> This is an error that occurs frequently and has made my todo file
> practically unusable. 
>
>     Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>       expand-file-name(nil)
>       find-file-noselect(nil nowarn)
>       todo-mode-external-set()
>       todo-edit-mode()
>       todo-edit-multiline-item()
>       call-interactively(todo-edit-multiline-item nil nil)
>       command-execute(todo-edit-multiline-item)
>
> Once such a thing happens the todo file which was good to begin with
> gets screwed and I really can do nothing more with it.

The only thing I can say for sure here is that this happens because
find-file-noselect tries to find the current todo file but for some
reason there is none.  This is certainly a bug, but to debug it I really
need a reproducible recipe.

> My STRONG RECOMMENDATION 
>
> To the users:
>
> - Beware of todo-mode to create real life todo entries.  It will make
>   you pay for it.

I'll do my best to lower the cost where I can.  Can you tell me
specifically what you consider overpriced?

> To the maintainer:
>
> - PLEASE! Compute the sexp for categories on demand.  Do you really
>   think that pre-computation is very much necessary speed up things on
>   large todo lists.

I'm not sure it is, but I tried to use the stored value only where
on-the-fly computation wasn't necessary.  Is there some place you think
I missed?

Steve Berman