GNU bug report logs - #20832
25.0.50; todo-show accidentally deleted my todo file.

Previous Next

Full log

View this message in rfc822 format

From: Nicolas Richard <nrichard <at> members.fsf.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 20832 <at> debbugs.gnu.org
Subject: bug#20832: 25.0.50; todo-show accidentally deleted my todo file.
Date: Thu, 18 Jun 2015 13:52:21 +0200

Le 18/06/2015 12:15, Stephen Berman a écrit :
> On Wed, 17 Jun 2015 07:39:59 +0200 Nicolas Richard <youngfrog <at> members.fsf.org> wrote:
> 
>> I managed to lose my todo-mode.el todo file. I don't really know how
>> this happened, I guess it was a combination of showing the todo file
>> while in the minibuffer and hitting C-g, but I noticed it too late, and
>> then could not reproduce.
> 
> Thanks for the report.  I can reproduce something that seems like what
> you describe; here's the recipe:

I'm very impressed you managed to find a recipe !

> 0. emacs -Q
>    M-x global-set-key RET C-c t RET todo-show RET
> 1. Type `M-x' to enter the minibuffer.

ISTR I was indeed in a M-x prompt when it happened.

> 2. If I now try to call todo-show by again typing `M-x', it fails with
>    the error "Command attempted to use minibuffer while in
>    minibuffer".

I have enable-recursive-minibuffers set to t, so I did not get this
error.

>    However, todo-show does not require minibuffer input, so when I type
>    `C-c t' it succeeds and displays the current todo category in the
>    minibuffer.
> 3. Now I cannot exit the minibuffer by typing `C-g', no matter how many
>    times.  However, `ESC ESC ESC' (keyboard-escape-quit) does exit the
>    minibuffer (by calling abort-recursive-edit),

I don't remember having to hit ESC ESC ESC, but my fingers know how to
hit C-] (abort-recursive-edit) so perhaps I did that. No idea.

Oh, but I now realize that I also have modified the binding of C-g to
call abort-recursive-edit in some conditions :

(defun yf/keyboard-exit ()
  "Throw an `exit' symbol" ;; modified from keyboard-quit
  (interactive)
  (cond ((region-active-p)
         (let (select-active-regions)
           (setq saved-region-selection nil) ; Avoid adding the region
                                        ; to the window
                                        ; selection.
           (deactivate-mark)))
        (defining-kbd-macro
          (kmacro-keyboard-quit)
          (setq defining-kbd-macro nil)
          (message "Macro cancelled"))
        (t 
         (let ((debug-on-quit nil))
           (if (> (recursion-depth) 0)
               (abort-recursive-edit)
             (user-error "Nothing to cancel."))))))

> Can you remember if this is what happened to you?

Well, it certainly looks like it.

>                                                    Note that even after
> the todo file is overwritten or deleted in step 5, you can still recover
> the deleted buffer contents as explained in step 4.

I tend to kill buffers blindly when I know I did not modify them on
purpose, so that's probably what caused the content loss. I had a backup
though, and didn't lose much data.

>                                              But if there are other
> triggers, then your patch may be needed.  However, since I haven't found
> any other way to make the problem you encountered occur, I'm inclined to
> install just the patch below; that way, if there is some other way to
> get an empty but modified todo-mode buffer, we may find it and be able
> to fix the underlying cause.

Throwing an error seemed like a good way to find such problems, to me,
better so than silently deleting the file.

>                               What do you think?
> 
> Incidentally, if `q' (todo-quit) is typed between steps 2 and 3 above,
> then the minibuffer becomes occupied by whatever other-buffer returns,
> and then typing `ESC ESC ESC' will result in that buffer being erased.

This is bad :'( It seems one should not change the buffer in a minibuffer
window. Perhaps it would be good if this was documented in
the docstring of set-window-buffer.

> So this is another reason to make sure todo-mode stays out of the
> minibuffer.

Yup.

> The following patch makes todo-show display the todo file in the
> previous window when invoked in the minibuffer.  An alternative would be
> to simply error out when invoking todo-show in the minibuffer.  But I
> think it could be useful to display the todo file while in the
> minibuffer.  Do you see a problem with this?

I don't see a need for (with-selected-window), but it looks ok ! Many
thanks for digging into this.

Nicolas.

Previous Next

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