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: Wed, 09 Dec 2020 21:11:39 +0200 Organization: LINKOV.NET Message-ID: <877dpqzx3o.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22848"; 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 Wed Dec 09 21:04:38 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 1kn5hW-0005oW-Ck for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Dec 2020 21:04:38 +0100 Original-Received: from localhost ([::1]:33968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kn5hV-0004Sg-Ay for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Dec 2020 15:04:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kn53J-0007dV-Ux for bug-gnu-emacs@gnu.org; Wed, 09 Dec 2020 14:23:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52833) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kn53H-0005x4-Ga for bug-gnu-emacs@gnu.org; Wed, 09 Dec 2020 14:23:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kn53H-0004FR-D1 for bug-gnu-emacs@gnu.org; Wed, 09 Dec 2020 14:23: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: Wed, 09 Dec 2020 19:23: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.160754173516200 (code B ref 45072); Wed, 09 Dec 2020 19:23:03 +0000 Original-Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 19:22:15 +0000 Original-Received: from localhost ([127.0.0.1]:36136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn52V-0004DE-6q for submit@debbugs.gnu.org; Wed, 09 Dec 2020 14:22:15 -0500 Original-Received: from relay11.mail.gandi.net ([217.70.178.231]:58381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn52U-0004Ck-DF for 45072@debbugs.gnu.org; Wed, 09 Dec 2020 14:22:14 -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 57BB3100005; Wed, 9 Dec 2020 19:22:05 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Wed, 9 Dec 2020 10:34:01 +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:195575 Archived-At: >> Thanks, sometime ago I asked how this would be possible to do, >> and now I'm testing your patch (it missed trailing spaces on diff >> context lines, but still applies without problems). >> >> It seems to be really useful this option needs to keep only windows >> implicitly created by the user, but remove windows created >> automatically by mibibuffer-related commands such as the buffer >> *Completions*. > > Such windows must be removed by the mechanism that created them. I > hardly ever see such windows here because I'm apparently using some > arcane completions mechanism that always puts them in place right away. > But if I'm not mistaken, several such windows may pop up during one and > the same minibuffer input operation and IMO all of them should pop down > automatically as soon as they served their purpose. > > A case could be made in the sense that by default the minibuffer window > itself won't shrink back after the completions have been shown there. > But I suppose that people using such a mechanism should also set > 'resize-mini-windows' to t. 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.