GNU bug report logs - #72487
calculator-electric-mode causes freeze on subsequent use of minibuffer

Previous Next

Package: emacs;

Reported by: Kevin J Witczak <kim.jet.wav <at> protonmail.ch>

Date: Tue, 6 Aug 2024 06:07:02 UTC

Severity: normal

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Kevin J Witczak <kim.jet.wav <at> protonmail.ch>, 72487 <at> debbugs.gnu.org
Subject: Re: bug#72487: calculator-electric-mode causes freeze on subsequent
 use of minibuffer
Date: Mon, 12 Aug 2024 11:50:49 +0200
[Message part 1 (text/plain, inline)]
> When using the calculator function of GNU Emacs 31.0.50 (bug also found
> in 29.4), usage of `calculator-electric-mode' causes Emacs to hang on
> subsequent uses of the minibuffer.
>
> Emacs -Q
>
> M-: (setf calculator-electric-mode t) <RET>
>
> M-x calcu <RET> q M-x M-p <RET>
>
> Note that the freeze does not depend on specifically calling calculator
> a second time, and calculator may be repeated with C-x z without issue.
>
> The freeze occurs specifically when the minibuffer exits a second time,
> even via C-g, before its contents are processed. Thus, for example, the
> following still yields a freeze:
>
> Emacs -Q
>
> M-: (setf calculator-electric-mode t) <RET>
>
> M-x d-o-e <RET> kill-emacs <RET>
>
> M-x calcu <RET> q M-x kill-emacs <RET>
>
> Apparently, calculator-electric-mode leaves the minibuffer window in a
> broken state after first usage, rather than resetting it correctly.
>
> Emacs must be killed externally at this point, and generally cannot be
> salvaged with C-g. It becomes trapped in a loop emitting terminal bells
> (seen with `visible-bell' mode on, or via a termscript from `-nw').

This bug is a consequence of accessing the list of previous buffers for
a minibuffer window.  That list is conceptually unmaintained and
therefore unsafe for minibuffer windows.  In particular, 'kill-buffer'
and subsequently 'replace-buffer-in-windows' do not consider minibuffer
windows.  The doc-string for the latter now states explicitly that
"Minibuffer windows are not considered."  Handling minibuffer windows in
'replace-buffer-in-windows' might require some deep surgery and is
certainly not recommended for a release branch.

I can offer the attached patch to provisionally handle this problem.

martin
[minibuf.diff (text/x-patch, attachment)]

This bug report was last modified 335 days ago.

Previous Next


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