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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72487 in the body.
You can then email your comments to 72487 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Kevin J Witczak <kim.jet.wav <at> protonmail.ch>
To: bug-gnu-emacs <at> gnu.org
Subject: calculator-electric-mode causes freeze on subsequent use of minibuffer
Date: Mon, 05 Aug 2024 22:41:57 +0000

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

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

Message #11 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: Fri, 23 Aug 2024 10:42:46 +0200

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

I now pushed it to the release branch.  Please check again with your
scenarios.

The patch does not fix a conceptual discrepancy between minibuffers and
their depth.  As an example, try with emacs -Q:

C-h f

M-x

(setq foo (window-buffer (minibuffer-window)))

C-h v

(kill-buffer foo)

Now C-g will tell me

completing-read-default: Selecting deleted buffer [2 times]

And ESC ESC ESC gets me

keyboard-escape-quit: No catch for tag: exit, t [6 times]
minibuffer-quit-recursive-edit: No catch for tag: exit, #[0 "\301\300\242S!\207" [(2) minibuffer-quit-recursive-edit] 2]

so I will be trapped in these for the rest of my session.

Since I do not consider killing minibuffers as something reasonable to
do, I won't try to fix this for the release branch.  The most simple
solution might be to inhibit killing of buffers used by the minibuffer
code.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 72487 <at> debbugs.gnu.org, kim.jet.wav <at> protonmail.ch
Subject: Re: bug#72487: calculator-electric-mode causes freeze on subsequent
 use of minibuffer
Date: Fri, 23 Aug 2024 16:18:03 +0300

> Date: Fri, 23 Aug 2024 10:42:46 +0200
> From:  martin rudalics via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
>  > I can offer the attached patch to provisionally handle this problem.
> 
> I now pushed it to the release branch.

Unless this is a recent regression (in Emacs 29 or since Emacs 29),
the release branch is not the right place to install this.  In the
latter case, please revert and install on master instead.

Thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72487 <at> debbugs.gnu.org, kim.jet.wav <at> protonmail.ch
Subject: Re: bug#72487: calculator-electric-mode causes freeze on subsequent
 use of minibuffer
Date: Sat, 24 Aug 2024 10:00:24 +0200

> Unless this is a recent regression (in Emacs 29 or since Emacs 29),
> the release branch is not the right place to install this.  In the
> latter case, please revert and install on master instead.

It's a regression in Emacs 29.

I spent about two hours hunting down this bug which misuses a feature I
introduced earlier in a very awkward way.  I'm still not sure how to fix
this completely.  That said, I think that it would be fair if, whenever
someone offers a patch for a reported serious bug (a bug that causes
Emacs to hang or crash), one of our maintainers explained within a week
or so how to proceed with the patch.

Thanks, martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 72487 <at> debbugs.gnu.org, kim.jet.wav <at> protonmail.ch
Subject: Re: bug#72487: calculator-electric-mode causes freeze on subsequent
 use of minibuffer
Date: Sat, 24 Aug 2024 12:27:32 +0300

> Date: Sat, 24 Aug 2024 10:00:24 +0200
> Cc: kim.jet.wav <at> protonmail.ch, 72487 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Unless this is a recent regression (in Emacs 29 or since Emacs 29),
>  > the release branch is not the right place to install this.  In the
>  > latter case, please revert and install on master instead.
> 
> It's a regression in Emacs 29.

In that case, let's leave the fix on the release branch.  Thanks.

> I spent about two hours hunting down this bug which misuses a feature I
> introduced earlier in a very awkward way.  I'm still not sure how to fix
> this completely.  That said, I think that it would be fair if, whenever
> someone offers a patch for a reported serious bug (a bug that causes
> Emacs to hang or crash), one of our maintainers explained within a week
> or so how to proceed with the patch.

I usually respond after 2 weeks if no one else chimes in, so your
installing of the patch beat me by a couple of days.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72487 <at> debbugs.gnu.org, kim.jet.wav <at> protonmail.ch
Subject: Re: bug#72487: calculator-electric-mode causes freeze on subsequent
 use of minibuffer
Date: Wed, 28 Aug 2024 10:59:58 +0200

[Message part 1 (text/plain, inline)]

Attached find a patch that should guarantee that only minibuffers are
recorded in a minibuffer window's list of previous buffers.  A ChangeLog
appears below.  If there are no objections, I'll install this on master
in two weeks.

martin

For minibuffer windows record minibuffers only (Bug#72487)

* src/minibuf.c (zip_minibuffer_stacks): Use wset type
functions.  Call 'record-window-buffer' instead of
'push-window-buffer-onto-prev' to handle all sorts of buffers
shown in minibuffer windows in a uniform way.
(read_minibuf): Call 'record-window-buffer' instead of
'push-window-buffer-onto-prev' for same reason as previous.
* lisp/calculator.el (calculator-update-display)
(calculator-save-and-quit): Make sure calculator buffer is live
before operating on it.
* lisp/window.el (record-window-buffer): Handle case where
WINDOW is a minibuffer window: Unconditionally remove WINDOW's
buffer from WINDOW's list of previous buffers and push it if
and only if it is a live minibuffer (Bug#72487).  Do not run
'buffer-list-update-hook' if WINDOW is a minibuffer window.
(push-window-buffer-onto-prev): Make it an alias of
'record-window-buffer' so it will run the latter's checks.
(replace-buffer-in-windows): Handle minibuffer windows and
rewrite doc-string accordingly.
* doc/lispref/windows.texi (Buffers and Windows): Explain
handling of minibuffer windows in 'replace-buffer-in-windows'.

[minibuffer-windows.diff (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72487 <at> debbugs.gnu.org, kim.jet.wav <at> protonmail.ch
Subject: Re: bug#72487: calculator-electric-mode causes freeze on subsequent
 use of minibuffer
Date: Wed, 11 Sep 2024 10:45:30 +0200

> Attached find a patch that should guarantee that only minibuffers are
> recorded in a minibuffer window's list of previous buffers.  A ChangeLog
> appears below.  If there are no objections, I'll install this on master
> in two weeks.

Installed on master.  If there are no further complaints, I'll close
this bug in a couple of days.

Belated and overdue thanks for the report.  I was clearly annoyed by the
fact that such stupid behavior could have crept into the code base.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72487-done <at> debbugs.gnu.org, kim.jet.wav <at> protonmail.ch
Subject: Re: bug#72487: calculator-electric-mode causes freeze on subsequent
 use of minibuffer
Date: Sat, 21 Sep 2024 10:07:14 +0200

> Installed on master.  If there are no further complaints, I'll close
> this bug in a couple of days.

Done.

martin

Previous Next

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