GNU bug report logs -
#45029
27.1.50; Regression: Yanking into externally modified file with delete-selection-mode
Previous Next
Reported by: Lars Ljung <lars <at> matholka.se>
Date: Thu, 3 Dec 2020 20:11:02 UTC
Severity: normal
Tags: confirmed, fixed
Found in version 27.1.50
Fixed in version 27.2
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #13 received at 45029 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 04 Dec 2020 11:18:29 +0100
> Cc: 45029 <at> debbugs.gnu.org
>
> Lars Ljung <lars <at> matholka.se> writes:
>
> > I get an error when I do this, and the content of the buffer is
> > completely replaced by a single "y".
> >
> > 1. Start with "emacs -Q"
> > 2. M-x delete-selection-mode
> > 3. Open some text file (fundamental mode)
> > 4. Modify the file externally
> > 5. While a selection is active, yank some text
> > 6. Answer yes to the question "<file> changed on disk..."
> >
> > The content of the buffer is now completely replaced by a single "y".
> > The message "No catch for tag: exit, nil" is shown in the minibuffer.
>
> I can confirm that this bug is still present in Emacs 28.
>
> The backtrace is included below, if that helps anybody.
>
> Debugger entered--Lisp error: (no-catch exit nil)
> throw(exit nil)
> exit-minibuffer()
> read-char-from-minibuffer-insert-char()
> funcall-interactively(read-char-from-minibuffer-insert-char)
> call-interactively(read-char-from-minibuffer-insert-char nil nil)
> command-execute(read-char-from-minibuffer-insert-char)
I'm guessing this is some unintended consequence of replacing
read-char-choice in userlock.el with read-char-from-minibuffer.
Juri, could you please look into this regression in Emacs 27? I'd
like to try to fix this for 27.2.
Thanks.
This bug report was last modified 1 year and 300 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.