[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 941a2e7: todo-mode: don't assume an ordering of tests

From: Glenn Morris
Subject: Re: master 941a2e7: todo-mode: don't assume an ordering of tests
Date: Tue, 30 May 2017 20:48:56 -0400
User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)

Stephen Berman wrote:

> Do you have any idea why our results differ?

I have no idea how todo-default-todo-file can get set to the right value
for you. (Maybe it's because you have files in ~/.emacs.d/todo, and I

> This backtrace means that the variables todo-current-todo-file,
> todo-global-current-todo-file, and todo-default-todo-file all evaluated
> to nil.  I don't see how that could happen with the test file, and when
> I start Emacs with -Q, eval the test file, instrument todo-show, run ert
> on the test todo-test-item-highlighting, and step through todo-show and
> todo-check-file, I see that todo-default-todo-file gets assigned
> todo-test-1.todo from the todo-resources directory as its value.

 todo-default-todo-file is a variable defined in 'todo-mode.el'
 Its value is nil
 Original value was "todo-test-1"

It is nil because the test file requires todo-mode before it sets
todo-directory. It mismatches its default because the default changes
when todo-directory does. (This seems to me like a not great way for a
defcustom to behave.)

So another solution that works for me is to not require todo-mode till
after you set todo-directory. As the FIXME comment in the test file
indicates, this setting of global variables isn't a good way to behave.

BTW, the test will hang with a "Do you want to convert.."  prompt if an
old todo file exists in ~/.emacs.d. Maybe make a macro that sets HOME to
a temporary directory with a copy of the input files, and use it in each

>   So I have no idea how this error could arise. And I also don't see
> how adding the sexp `(todo-test-get-archive 2)' prevents it, since
> that just displays the file todo-test-1.toda in todo-archive-mode (and
> that file becomes the buffer-local value of todo-current-todo-file).
> Can you reproduce the error,


> and if so, could you try debugging it?

See above. :)

> if you don't have time for that, could you tell me why you used that
> specific change to avoid the error?

I looked at it very briefly, and thought: "nothing is telling
todo-test-item-highlighting which source file to use;
todo-test-get-archive is the only place in the file that seems to set a
source file; I'll stick that in; now it works.".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]