From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs 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 10:32:54 +0200 Organization: LINKOV.NET Message-ID: <87wnxqxdx5.fsf@mail.linkov.net> References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19822"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 10 09:36:31 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1knHR8-000537-Hi for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 09:36:30 +0100 Original-Received: from localhost ([::1]:56778 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knHR7-00033w-Ci for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 03:36:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knHPj-0002MO-Jh for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 03:35:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53652) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knHPj-0008MV-Co for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 03:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knHPj-0002rv-AD for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 03:35:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Dec 2020 08:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45072 X-GNU-PR-Package: emacs Original-Received: via spool by 45072-submit@debbugs.gnu.org id=B45072.160758927110973 (code B ref 45072); Thu, 10 Dec 2020 08:35:03 +0000 Original-Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 08:34:31 +0000 Original-Received: from localhost ([127.0.0.1]:36963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knHPD-0002qu-B7 for submit@debbugs.gnu.org; Thu, 10 Dec 2020 03:34:31 -0500 Original-Received: from relay11.mail.gandi.net ([217.70.178.231]:50031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knHPB-0002qa-Vj for 45072@debbugs.gnu.org; Thu, 10 Dec 2020 03:34:30 -0500 Original-Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98]) (Authenticated sender: juri@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id E0EA2100009; Thu, 10 Dec 2020 08:34:21 +0000 (UTC) In-Reply-To: <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> (martin rudalics's message of "Thu, 10 Dec 2020 08:44:57 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195623 Archived-At: > 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 What do you type to accept a suggestion? I can't find a key to accept a suggestion without exiting the minibuffer. > (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. Then maybe the commands that pop up the completions window should clean up their windows after use. What would be the right place to remove used windows? Maybe in exit-minibuffer? Or in some unwind-protect in case the user types C-g? > 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. This means that quit-window should be used on the completions window. It should do the right thing: either restore a previous buffer in that window, or close the window if no more buffers were displayed in it. > 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. That's fine, I create a new tab when the minibuffer is active, to preserve new windows created during the active minibuffer. For more convenience, now I installed a patch that allows creating a new tab even from the minibuffer.