From: Nicolas Richard <nrichard@members.fsf.org>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: 20832@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 [thread overview]
Message-ID: <5582B0F5.30303@members.fsf.org> (raw)
In-Reply-To: <87fv5pcogr.fsf@gmx.net>
Le 18/06/2015 12:15, Stephen Berman a écrit :
> On Wed, 17 Jun 2015 07:39:59 +0200 Nicolas Richard <youngfrog@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.
next prev parent reply other threads:[~2015-06-18 11:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 5:39 bug#20832: 25.0.50; todo-show accidentally deleted my todo file Nicolas Richard
2015-06-18 10:15 ` Stephen Berman
2015-06-18 11:52 ` Nicolas Richard [this message]
2015-06-19 6:43 ` martin rudalics
2015-06-19 15:15 ` Stephen Berman
2015-06-19 15:39 ` martin rudalics
2015-06-19 15:14 ` Stephen Berman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5582B0F5.30303@members.fsf.org \
--to=nrichard@members.fsf.org \
--cc=20832@debbugs.gnu.org \
--cc=stephen.berman@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).