GNU bug report logs - #78608
31.0.50; Todo mode bug revealed by setq-default change

Previous Next

Full log

Message #8 received at 78608 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78608 <at> debbugs.gnu.org
Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change
Date: Wed, 28 May 2025 13:45:33 +0300

> Date: Tue, 27 May 2025 17:53:24 +0200
> From:  Stephen Berman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Trigger: After I debugged the problem on master and came up with the
> above patch, I wondered why I had never encountered the problem until
> recently, because most of the code involved hasn't changed since the
> current version of Todo mode was added to the Emacs repo twelve years
> ago.  So I executed the above recipe in the emacs-30 branch and was
> surprised to find that the bug does not happen there: after step 5, the
> category "test1" is displayed and there is no prompt for a Todo item.
> Debugging showed that this is because the value of `todo-categories' is
> nil in emacs-30, both before and after specifying a category to jump to.
> This difference between emacs-30 and master manifests itself in the
> function `todo-category-completions' (called from `todo-read-category')
> around the following code:
> 
> (with-current-buffer (find-file-noselect f 'nowarn)
>   [...]
>   (todo-mode)
>   [...])
> 
> In both master and emacs-30, before entering this sexp, the buffer-local
> value of `todo-categories' is nil, but after invoking `todo-mode' its
> value (for the buffer visiting the Todo file `f') becomes non-nil.
> After leaving the `with-current-buffer' form, `todo-categories' retains
> its non-nil value in master, but reverts to nil in emacs-30.  The mode
> function `todo-mode' calls `todo-modes-set-3', which contains the form
> `(setq-local todo-categories (todo-set-categories))'.  This led me to
> commit f3e0bdf1b98, and indeed, when I undo that change in master, the
> problematic prompt on calling `todo-jump-to-category' does not happen.

Stefan, I think this means we need to call out this change in NEWS as
an incompatible change (unless you think there's a bug in that change
which needs to be fixed, and will make this change compatible).

> Problem (pre-master): Then I tested invoking `todo-jump-to-category'
> from outside of a todo-mode buffer and specifying a non-existing
> category, and saw the same pattern, which, however, now reverses the
> problem status: the new (empty) category is displayed and there is the
> now expected prompt for a Todo item in master but, now wrongly, not in
> emacs-30; thus, in this case the behavior in emacs-30 (and earlier)
> contradicts the documentation.  To reproduce, carry out the above recipe
> (in master and in emacs-30), but in step 5 enter "test2" at the prompt
> instead of "test1".  (When I implemented `todo-jump-to-category', I
> apparently failed to test this case and haven't made use of it since.)
> 
> Applying the above patch to emacs-30 also fixes this problem, and with
> the patch the other case (specifying an existing category) still works
> correctly in emacs-30.  The fact that the latter case also works
> correctly in emacs-30 without the patch is evidently due to the
> problematic behavior of `setq-local' fixed by f3e0bdf1b98.  The patch
> has a narrow scope, so I think it's safe enough to commit to emacs-30,
> even though the bug there is not a regression; but if that's not
> acceptable, I'll commit it to master.

I'm okay with committing this to emacs-30.

Previous Next

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