GNU bug report logs - #45072
28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

Previous Next

Package: emacs;

Reported by: Jean Louis <bugs <at> gnu.support>

Date: Sun, 6 Dec 2020 14:09:01 UTC

Severity: minor

Tags: fixed

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, Jean Louis <bugs <at> gnu.support>, 45072 <at> debbugs.gnu.org
Subject: bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing
Date: Thu, 10 Dec 2020 08:44:57 +0100
> What do you think about let-binding a new variable
> read-minibuffer-record-windows to nil around functions
> that pop up completion windows?
>
> I mean for example in minibuffer-completion-help:
>
>    (let ((read-minibuffer-record-windows nil))
>      (display-completion-list completions))
>
> The default value of read-minibuffer-record-windows could be t,
> so it will record new windows created by the user, e.g. by C-x 2.
> But when let-bound to nil, it won't record windows created
> by completion commands, so these windows won't be restored
> after exiting the minibuffer.

We'd have to augment the 'quit-restore' mechanism somehow and run it on
all windows instead of restoring the configuration.

But I still don't understand the logic of the following:

(1) Start minibuffer interaction, type a-

(2) Pop up a completion window for a- and accept suggestion a-b

(3) Type another - so you now get a-b-

(4) Pop up a completion window for a-b- and accept a-b-c

In this scenario I'd want, after accepting a-b, the completion window to
disappear (or show its old buffer again) without the minibuffer action
having terminated.  So I'm still convinced that restoring a previous
state should be triggered by the completion mechanism and not by the
read from minibuffer mechanism.

One thing that has to be considered too is user interaction during
completion: Suppose I have one window, the completion mechanism pops up
a new one and I delete the old one.  Terminating completion now cannot
delete the new window (especially if it's on the only frame in use) but
has to show another buffer in the new window.  It maybe should try to
show the one previously shown in the old window.

And let's not forget that the completion mechanism might pop up a new
frame or a window on any other frame.  In such case, restoring window
configurations won't help at all.

martin




This bug report was last modified 3 years and 291 days ago.

Previous Next


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