unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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).