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

Full log

View this message in rfc822 format

From: Jean Louis <bugs <at> gnu.support>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 45072 <at> debbugs.gnu.org, larsi <at> gnus.org, Juri Linkov <juri <at> linkov.net>
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 11:30:44 +0300

* martin rudalics <rudalics <at> gmx.at> [2020-12-10 10:45]:
> > 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.

I am trying to see relevance here, maybe I miss something. The
built-in completion does not replace the window which I am looking it.
It may make its visible part somewhat smaller, but not replace it.

Then I change buffers in those windows. Apart from being made somewhat
narrower, windows are not replaced by completion. 

And I did not even use completion. I was entering information on minibuffer.

> 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

I have not ever see that in built-in Emacs completion. But maybe it exists. 

I have seen completion poping up new window, but not replacing or
deleting other window.

Jean

Previous Next

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