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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Jean Louis <bugs@HIDDEN>; dated Sun, 6 Dec 2020 14:09:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 15 Dec 2020 08:00:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 15 03:00:03 2020
Received: from localhost ([127.0.0.1]:55406 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kp5Fa-0001td-SP
	for submit <at> debbugs.gnu.org; Tue, 15 Dec 2020 03:00:03 -0500
Received: from mout.gmx.net ([212.227.17.21]:36803)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1kp5FY-0001sb-4r
 for 45072 <at> debbugs.gnu.org; Tue, 15 Dec 2020 03:00:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1608019162;
 bh=stlK7oDE2oE0MbjDHNf1RO3IUTSdxPx/UHcUio55Msg=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=KSbC8opTjCd92vO+IyLr7NcEqk6x8npbYARLmjkyXhTnpC5uATO/FXyKuSediUWbh
 mVYFwERyINcMXNB2RcUTeMGHK5mDZOfWpUmlDhqfqrusak5PHa3wuJqW0NS053lOuB
 8Ee3zEoMNad3DOBo9UFp7QSm8YX5oWgOdm6i2yUU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([212.95.5.82]) by mail.gmx.com (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mi2Jt-1kBurj236X-00e2tu; Tue, 15
 Dec 2020 08:59:22 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Juri Linkov <juri@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
 <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
 <87pn3e697i.fsf@HIDDEN>
 <35666a8a-6888-972c-4e20-bf05cf09d764@HIDDEN>
 <87tuso16qn.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <8f134c6c-58e4-96f9-ec43-c16f781dc64f@HIDDEN>
Date: Tue, 15 Dec 2020 08:59:21 +0100
MIME-Version: 1.0
In-Reply-To: <87tuso16qn.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:6UceH5Rfb/3WCnJxA4igedf8eglmBlw+eHveKgDTyik4Joy1qVI
 vwM+FA1MXCbqs61hpKjCOwXUGxMNi0aaSfK8YK/IMkRZeuEdYxjkx83Ii7Sz0kgc0EVk0BW
 Nve7aGgfOvCcl3Eds+DXPr1HwlFng2unMKoU9FRYU0GmCHSpjxQP4SErJHEDlv5scoZeuwO
 R15P2S+th+TT2UUEVQZcg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:BrKocypAbzI=:zClD8capud4SGFHwdyrtBy
 uCDrZQoF0xRbSrYG9XZKhdqneYA2yXeLXMQiBvJK73Mr1eT/nbQ+QkxEF5PvU2G5QCU600Ulx
 FbS8YvdYgkTKiq9BL8s/0z8B6g6ZmJHxXmSF2QTl/z2QO8u/nQHPzbJf6leMjMGtRZMzc74vN
 NMEjz2lUeKEM9HYkUkYRE6kOWV+eey1dLweViVPQYTs8XEr/G1UholgOeHmG27nb6yQK2u1FZ
 SGqtbtpXSmb5nswc/7pJpSujyggmyhdB2TQYi5g8Hpb/QcsLaBWxuxySf/LQUlqajUapsHfyj
 2Kmi74C+cqujdXeeU5BWsw/B9lgN8tItLRXrZzWSmpNjSlJeuTnVlcYuHKsLte/buP4yKUo+X
 aiR0gFyQPGrxW/EgBIeeE7Mt37WeKqtIQZw9cdYOt0d7hHX0UKjqq7kMVWrPXkQMGqQXIwyo8
 aK3uYiSQxoUq9Vbpu2PB/Bv7XK8YpZomPyRgrgyydMXlvmXuUj/aBnbtNxJbMzA5HIMIQKxi3
 ECJbs9lNtJBiuOLmfphGEwS2ql14NcFQDQZx3aZOKuclDk7xSC5Byty89exuTbYitiIZqel3t
 PEKtHkdHb/6MHCYsu8bNX/wD4XngHIw7NuCDrc7Sx5P/3euk4cAanAZ26HbEvcKzdhcpgS7yu
 WI3nEhUhj3nnvH0PJgQimdxbVBloQ35c4UNIDVeryj67GULaUXfBdPgPaVPBB/wKuiZZK7Ie4
 ptYaYZRqNnI69QDryOK7JCUbUaYLv5a3E06FrcOmb5b4fGxQEPIrZSzT1J134wua4A8kZ3AUV
 Ye5PJNAfiuTZeVL5ldp4NoQHHl7kq6Iz1DX5ZKgAp8qXr1Ck8OKM8SwA/MB6CGz62wWsTPdGE
 wh5NS7Uew0PMM5uq6djgpqfSoeTm0BSWXLb1N3YKc=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > I tried your previous patch and it has strange effect:
 > > C-x 2 C-x o - so the bottom window is selected. > > C-h f C-g - after
 canceling the minibuffer, the top window is selected, > not the bott [...]
 Content analysis details:   (2.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [212.95.5.82 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (rudalics[at]gmx.at)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [212.227.17.21 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [212.227.17.21 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > I tried your previous patch and it has strange effect:
   > > C-x 2 C-x o - so the bottom window is selected. > > C-h f C-g - after
   canceling the minibuffer, the top window is selected, > not the bott [...]
    
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [212.227.17.21 listed in list.dnswl.org]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [212.95.5.82 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [212.227.17.21 listed in wl.mailspike.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (rudalics[at]gmx.at)
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

 > I tried your previous patch and it has strange effect:
 >
 > C-x 2 C-x o - so the bottom window is selected.
 >
 > C-h f C-g - after canceling the minibuffer, the top window is selected,
 > not the bottom window as before activating the minibuffer.

Should be part of the recent "Stop frames stealing each others'
minibuffers!" rampage.  We can look into it when the dust settles -
there are still bugs to fix and riddles to solve in that area.  Till
then it would be good to try the patch on Emacs 27 to catch any
anomalies ...

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 14 Dec 2020 20:37:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 15:37:57 2020
Received: from localhost ([127.0.0.1]:54658 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koubV-0002tZ-Gf
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 15:37:57 -0500
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:50981)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1koubU-0002tJ-Ax
 for 45072 <at> debbugs.gnu.org; Mon, 14 Dec 2020 15:37:56 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id B192D240003;
 Mon, 14 Dec 2020 20:37:47 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Organization: LINKOV.NET
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
 <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
 <87pn3e697i.fsf@HIDDEN>
 <35666a8a-6888-972c-4e20-bf05cf09d764@HIDDEN>
Date: Mon, 14 Dec 2020 22:28:40 +0200
In-Reply-To: <35666a8a-6888-972c-4e20-bf05cf09d764@HIDDEN> (martin rudalics's
 message of "Sun, 13 Dec 2020 08:26:34 +0100")
Message-ID: <87tuso16qn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> I tried to add it to 'exit-minibuffer', and it seems working fine
>> with non-nil read-from-minibuffer-restore-windows, and I know no other
>> place that could call minibuffer-hide-completions:
>
> But 'minibuffer-hide-completions' uses 'bury-buffer' which would delete
> the completions window unconditionally even when it was only reused for
> showing completions.  IMO 'bury-buffer' is practically always the wrong
> choice for Lisp functions to call.

Maybe 'quit-window' is better?

I tried your previous patch and it has strange effect:

C-x 2 C-x o - so the bottom window is selected.

C-h f C-g - after canceling the minibuffer, the top window is selected,
not the bottom window as before activating the minibuffer.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 13 Dec 2020 07:27:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 02:27:16 2020
Received: from localhost ([127.0.0.1]:47354 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koLmm-0007nt-5f
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 02:27:16 -0500
Received: from mout.gmx.net ([212.227.17.22]:47531)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1koLmk-0007nU-5u
 for 45072 <at> debbugs.gnu.org; Sun, 13 Dec 2020 02:27:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607844396;
 bh=zn3F2YwELI5sGBEgo8TRvXLQMJqbN70xpbDnZMsk9Qw=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=BVjodZzE3Fa7//QsPqEhelc/4ueYo2oojkl55TP2pBlH8ANFjhYkA/GunysgFpse5
 KBP4uR+FnzUpNdolxgXGqkGV1wvRurl0GgmmYAeIDlWwsnoTOPlizlkUFJCqPyXcdh
 DrAu6NUMbR6cYoJf1kKkbkBsZnGTnXcoG/d2ST10=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([212.95.5.101]) by mail.gmx.com (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MeU4y-1kDv5s0mma-00aUgN; Sun, 13
 Dec 2020 08:26:36 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Juri Linkov <juri@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
 <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
 <87pn3e697i.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <35666a8a-6888-972c-4e20-bf05cf09d764@HIDDEN>
Date: Sun, 13 Dec 2020 08:26:34 +0100
MIME-Version: 1.0
In-Reply-To: <87pn3e697i.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:IOKR4bsRTnNrSfHJato+1VhKW64dd+CjYX/HNkXcNZ2eUNy0mJS
 M5jXWdgDt54eeIt5b702XNSTqEB1oORfLRPo/YbBQs23E7KWnQszjw4BNwqVs34caPsopjn
 6V9kP0p0QueyM4W+DFOdRbVCi259lLgNVUaIWkD+//0kOCaCsB+L1pscvqaGsr1fkewUH1F
 eKBE+VI0KAccknB7ltSLQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:663LiHweLnk=:Ic+TqpcPNdFLy9xpzzbe7H
 JKSQizWCQuPqBij2G8RcRwXOZC0J22kxgXzcpBhMuaZ7jzRab1bSPPXrS6Uv68hfzs48OofXg
 OjFv4PWb5CJZkkW8DnIhZJzp3NQvUFahzyGVo6zT2Sffxw0Rcx2GbM+ugnElNlBLkZj3APJCE
 V8U9kWiknVSKnbIKw6/A5/tQzBIpyMzCydRs0QeEcLQxuoOmkiU6uLoyGZIm3LtiaOTIJlWbN
 8AUdeCS/TdHUxYddlAxNl1jeoxUOK1av/GlzlzhM8fWyHSRWYeR4/JQT2TXpvxgLAFYChs2oS
 wLv+ExaroWY2a+N9/EMWjdvOOCkPbgHEJ4HIZbjbDTcY17iTfm/Xh0P+Pmr25+iAH6O4yCnqt
 nl/jqOv63puDz++kTS25sfGCLQ+hm7FDx7tAulcGIVOOO1X57DAGC2dWfFQSGahw1mlubW961
 r/AJzw7xgr7ed7dOQcLFrFf2XABAwS60rljhkbP6Ii37DxJk7vj9P3osw1DoMw/dwLYY/MOZC
 cHR1C4AbFL76YtYZ+34jiyxMdD4HmCAliAsXG2RGF/6ijR/L4tduaS5eBCzVo9jZ3VDv01bKW
 +JlOo+0z1dT0W0jqpQ7VrlfcDHlM9yUUDHM0jR2WiLEqarZ3+iCSOZLRySOGUpVwyIZd+I/c6
 3y5uDg//dyWPJ8GgGfOdQzwqTiD3tja++WA4zOjV+SBdIqNhoMpCjQAYkiJnwFIBG1+/Og/78
 b2gLHRZZYyEysxkUYOm0E1HWFnizbt9l4SfIGpPps5TPw0Nlx7WcZLWHgbxNdtynh509mq4As
 Fx7SX1x6QaxG7u4ykTA7+qNuRQe1y3r4fyr1k6xo/H0ZQIzqjkwHE+x8Mxe/PqacMY8Cjnp8G
 L+58CvTguoGp6tFYdzhw==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > I tried to add it to 'exit-minibuffer', and it seems working fine
 > with non-nil read-from-minibuffer-restore-windows, and I know no other
 > place that could call minibuffer-hide-completions:

But 'minibuffer-hide-completions' uses 'bury-buffer' which would delete
the completions window unconditionally even when it was only reused for
showing completions.  IMO 'bury-buffer' is practically always the wrong
choice for Lisp functions to call.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 12 Dec 2020 21:08:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 12 16:08:52 2020
Received: from localhost ([127.0.0.1]:46921 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koC8K-0004vA-Ft
	for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 16:08:52 -0500
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:60599)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1koC8H-0004ug-2U
 for 45072 <at> debbugs.gnu.org; Sat, 12 Dec 2020 16:08:49 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CD85560002;
 Sat, 12 Dec 2020 21:08:41 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Organization: LINKOV.NET
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
 <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
Date: Sat, 12 Dec 2020 22:49:37 +0200
In-Reply-To: <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN> (martin rudalics's
 message of "Thu, 10 Dec 2020 10:47:21 +0100")
Message-ID: <87pn3e697i.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> 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?
>
> The completion mechanism should clean up its traces as soon as it is
> finished - either a choice has been made or it has been aborted: This
> can mean to clean up windows or frames, size back a minibuffer window or
> remove a pop up menu or a dialogue box.  But I hardly ever use that
> mechanism so I cannot tell how it works (or should work) in practice.
>
> In either case 'exit-minibuffer' is too late.  It must be either the
> caller of completions - just in case it wants to, for example, reuse the
> present window for refining the list of completions - or the called
> which might be more noisy with windows popping up and down.  And I
> suppose that completions are not invoked from minibuffer interactions
> alone ...
>
>> 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.
>
> Yes.  But IMO that should be done _before_ reading from the minibuffer
> interaction finished.

There is an existing function 'minibuffer-hide-completions'.  For example,
it's used in completion-in-region-mode this way:

        (unless (equal "*Completions*" (buffer-name (window-buffer)))
          (minibuffer-hide-completions))

I tried to add it to 'exit-minibuffer', and it seems working fine
with non-nil read-from-minibuffer-restore-windows, and I know no other
place that could call minibuffer-hide-completions:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 456193d52e..63b9c9996a 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2114,6 +2114,7 @@ minibuffer-hide-completions
 (defun exit-minibuffer ()
   "Terminate this minibuffer argument."
   (interactive)
+  (minibuffer-hide-completions)
   ;; If the command that uses this has made modifications in the minibuffer,
   ;; we don't want them to cause deactivation of the mark in the original
   ;; buffer.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 12 Dec 2020 01:50:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 11 20:50:53 2020
Received: from localhost ([127.0.0.1]:43663 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knu3h-0000c5-2h
	for submit <at> debbugs.gnu.org; Fri, 11 Dec 2020 20:50:53 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:56813)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1knu3c-0000bn-9H
 for 45072 <at> debbugs.gnu.org; Fri, 11 Dec 2020 20:50:51 -0500
Received: from localhost ([::ffff:41.202.241.42])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 00000000000442C7.000000005FD421F0.00007B19; Fri, 11 Dec 2020 18:50:40 -0700
Date: Sat, 12 Dec 2020 04:47:49 +0300
From: Jean Louis <bugs@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X9QhRdmlfw1B7ETs@HIDDEN>
References: <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <X9HctL/WTECDMiD8@HIDDEN>
 <8f775254-65d2-6f3d-4c71-b6f10bb2b278@HIDDEN>
 <X9H1YVXQHzSU0woG@HIDDEN>
 <a74f9c51-593f-c249-029a-1de9982005dc@HIDDEN>
 <X9IPjit9MlsZ0wEq@HIDDEN>
 <874kksoeq7.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <874kksoeq7.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: martin rudalics <rudalics@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* Juri Linkov <juri@HIDDEN> [2020-12-11 13:00]:
> > I would rather prefer replacement than third window jerking other two
> > up and rendering them not usable. But that is not subject of this bug report.
> 
> Currently *Completions* are displayed by 'display-buffer-at-bottom'.
> You can customize this with:
> 
> (push `("\\`\\*Completions\\*\\'" display-buffer-use-some-window)
>       display-buffer-alist)

Thank you, I know you already said it before and I kept email until I
try it out. Now I finally tried it. This will become part of my
init.el






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 11 Dec 2020 10:00:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 11 05:00:00 2020
Received: from localhost ([127.0.0.1]:40021 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knfDU-0007R5-2y
	for submit <at> debbugs.gnu.org; Fri, 11 Dec 2020 05:00:00 -0500
Received: from relay10.mail.gandi.net ([217.70.178.230]:38427)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1knfDJ-0007QP-Rk
 for 45072 <at> debbugs.gnu.org; Fri, 11 Dec 2020 04:59:51 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id AF847240016;
 Fri, 11 Dec 2020 09:59:40 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Jean Louis <bugs@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Organization: LINKOV.NET
References: <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <X9HctL/WTECDMiD8@HIDDEN>
 <8f775254-65d2-6f3d-4c71-b6f10bb2b278@HIDDEN>
 <X9H1YVXQHzSU0woG@HIDDEN>
 <a74f9c51-593f-c249-029a-1de9982005dc@HIDDEN>
 <X9IPjit9MlsZ0wEq@HIDDEN>
Date: Fri, 11 Dec 2020 11:39:32 +0200
In-Reply-To: <X9IPjit9MlsZ0wEq@HIDDEN> (Jean Louis's message of
 "Thu, 10 Dec 2020 15:07:42 +0300")
Message-ID: <874kksoeq7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: martin rudalics <rudalics@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> I would rather prefer replacement than third window jerking other two
> up and rendering them not usable. But that is not subject of this bug report.

Currently *Completions* are displayed by 'display-buffer-at-bottom'.
You can customize this with:

(push `("\\`\\*Completions\\*\\'" display-buffer-use-some-window)
      display-buffer-alist)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 12:44:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 07:44:19 2020
Received: from localhost ([127.0.0.1]:37188 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knLIw-0002qW-Rg
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 07:44:19 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:49163)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1knLIt-0002q5-HE
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 07:44:15 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 000000000001E529.000000005FD21818.0000298B; Thu, 10 Dec 2020 05:44:08 -0700
Date: Thu, 10 Dec 2020 15:21:42 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X9IS1ie3dc0EBAnV@HIDDEN>
References: <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
 <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
 <X9H2k6W4WrMLFjz1@HIDDEN>
 <f947a9da-127f-2aef-94c2-d411f5711cd0@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <f947a9da-127f-2aef-94c2-d411f5711cd0@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* martin rudalics <rudalics@HIDDEN> [2020-12-10 14:53]:
> > It is interesting and suprising to see how people use Emacs in different way.
> 
> I don't use Emacs that way.  But I incidentally noticed that when using
> Emacs that way I can pop down the completions window without terminating
> the minibuffer interaction.

Probably majority of users do not use minibuffer much. I am using it
frequently for database queries and repetitive editing of database
values. Often I have tabulated list mode showing database entries,
with one click I edit such lines in the minibuffer.

Many times I move from minibuffer to other windows, switch buffer, get
references, come back.

That means I am reusing Emacs interface features. Other programmers
would program their GUIs in Gtk or other GUI frameworks. To spare
efforts and times I find Emacs useful for reuse of code. Not because
it is best, because it has useful features for quick reuse. And it
works on console as well.

Thinking on what you said, I could maybe replace minibuffer input for
some functions. I could use forms.el for example. Or similar like
defcustom for variables.

Definitely I would not like having interface that does not work on
console alone.

Minibuffer is handy for single lines. One could accept with C-q C-j a
new line in the minibuffer, but is unlikely to happen. This makes it
handy for various database entries such as names, email addresses and
similar. I am using full buffer when entry should span few lines. So I
am using Emacs interface to help with database entry validation. But I
should rather use program and the database to make sure of entry validation.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 12:44:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 07:44:16 2020
Received: from localhost ([127.0.0.1]:37186 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knLIu-0002qN-Jc
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 07:44:16 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:44481)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1knLIr-0002q2-C5
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 07:44:15 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 000000000001E527.000000005FD21814.00002977; Thu, 10 Dec 2020 05:44:04 -0700
Date: Thu, 10 Dec 2020 15:07:42 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X9IPjit9MlsZ0wEq@HIDDEN>
References: <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <X9HctL/WTECDMiD8@HIDDEN>
 <8f775254-65d2-6f3d-4c71-b6f10bb2b278@HIDDEN>
 <X9H1YVXQHzSU0woG@HIDDEN>
 <a74f9c51-593f-c249-029a-1de9982005dc@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <a74f9c51-593f-c249-029a-1de9982005dc@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* martin rudalics <rudalics@HIDDEN> [2020-12-10 14:52]:
> >> All these scenarios are with customizations.  I'm not experienced enough
> >> to tell whether they (can) happen in practice.
> >
> > Do you refer to standard completion in minibuffer that it may be
> > customized to replace a present window with the completion instead of
> > opening new windows?
> >
> > That would be nice as I would like to avoid those jerks when there are
> > 2 horizontal windows and then third one appears for completion jerking
> > both of them up and narrowing those visible windows to almost
> > invisible rendering both of them unusable.
>
> Doesn't it do that already?  Note that here and elsewhere I'm purely
> speculating how application writers and users might tweak things.

That is what I am pointing to, it does not do that what you described,
so descriptions misses the point. They don't apply.

 When I have this window:

  +---------------------+
  |                     |
  |                     |
  |                     |
  |                     |
  +---------------------+
  |                     |
  |                     |
  |                     |
  |                     |
  |---------------------|
   +--------------------+

Then upon completion it becomes this:

  +---------------------+
  |                     |
  +---------------------+
  |                     |
  +---------------------+
  |                     |
  | completion here     |
  |                     |
  |                     |
  |                     |
  |                     |
  |---------------------|
  +---------------------+

So the third window appears there. It is not replacement. I would
rather prefer replacement than third window jerking other two up and
rendering them not usable. But that is not subject of this bug report.

> These should be already addressed by my earlier patch.  But Juri meant
> that we have to handle completions windows separately since otherwise
> they may persist.

Thank you, I will try but not ready. My version is days old, need to
upgrade to new version to test the patch.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 11:53:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 06:53:15 2020
Received: from localhost ([127.0.0.1]:37148 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knKVX-0007uf-9x
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 06:53:15 -0500
Received: from mout.gmx.net ([212.227.15.18]:35925)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1knKVV-0007uR-HX
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 06:53:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607601157;
 bh=hMpOXzj3F7pmJRQO49v3YdjROZ96R3iZn0m9gokGoPo=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=cdwprz0CC0MkLdE/KR12oBk3osVYIkz2FlbCb5XuWw1M3dOYapnyl3CP4FDPv4go8
 eqAKr4IuJYwntmB4O9BRPy9eUJzM5E2ym31VjYFwATgjWvsy62ASds6N7nCbFS2jze
 67tC8Yuadb3MqbDTr80UIe28LV4bv0xm+x+OxH4U=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([212.95.5.249]) by mail.gmx.com (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8ofE-1k1jtq3XMs-015rET; Thu, 10
 Dec 2020 12:52:36 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Jean Louis <bugs@HIDDEN>
References: <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
 <835z5d8lhc.fsf@HIDDEN> <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
 <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
 <X9H2k6W4WrMLFjz1@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <f947a9da-127f-2aef-94c2-d411f5711cd0@HIDDEN>
Date: Thu, 10 Dec 2020 12:52:36 +0100
MIME-Version: 1.0
In-Reply-To: <X9H2k6W4WrMLFjz1@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:h8pqVOQD6HWssalvuF5WRaLEB7FLnPya95JlTYJH2uqWVtGnIGx
 WvLrrSBQzTZGEeQBaBsHRwgZdBEbqZf8E9a6Ett3XOeKBDNF6XoTFXC8CwMpqZhaOi6TgAY
 jeSE1b4JrG3KM5+ca8AZacqyQpDnmhO73S9U8oEwYVsGwMgp1jmbX5K1nrgnfpWKu8aK5V3
 sv9kkUDBBzAZ9lYEKwVSQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:w1pIiaBjf0A=:9Z7+36PByd02rIbjB4DVum
 lF4kwanVzUY7h2bkF6iyyS8e8ai1Hj7UVZN+8I4KGBIxGu1sUAo+XgqvF9+0WC63fCLK37Pzp
 Qll4HM+HwFBJvZ1NI1ouXVm1aQz04IrYIA0EyLbMISUG6tE08TGD38B5C0A2GhTTaOQzo4cHV
 M21DEx9U/XQUrfqXSOVHkPSSdtCV0AlqkjfpWuNrk0IFyjUoNyLRDnmn5jiWf2l7CIToFMv3L
 W4HdjXGz5ANCWloB2+eiQfrx3arWCh4MwbNpsunlirZSSfh0sNCO5BCQutGbWfWIsNg+SpwqZ
 MfnQ4nW/ad9Ie8I6h9Si6tglhJEE9NOxbGvfcY/dNxAbejx/Gr9FpzG3lV+QyFaK5oN/2aYmH
 U8cyEabaBCdUm6S7d9wnQ5gOhRItYDqg/gmP8cP1KI5hEDwvE1cMBLVN33jF2eSObcYxqNG4V
 XY62qgJQ19fr3X/VVnmv4D0O+xYNL23oW7ZpNaWynJRRjSCWpXgS81EXX9VfWQ9NPwe9ZAgnA
 zXvy9fInbM5oKCt57+FBDMO52fj+qKWArfTW8WbWPX32w7R3Ocs0uaK4z2Dj3RBaHMa0mWuNq
 qAVN1r1wkVITse7n0IHEdZOEKcXEKmXeG5iyCl4qb8iZsWb52llvvExvxZGHUebXgrEkN9LGI
 3dNku0Pjw8uKBXhiOhSAkVy2vkgcHwONiRdAj0WxPvijQnsDYFjjGY/UAjwKOIiX5JppENtSp
 955Qli2pU68xBe1203/eOFeEXWbN4vicThXaXTo7pmK8AuR6n4UOv2CzqPh9jWABP7yYWdyTR
 JDkEFeN0vNkaq6CSRu5HgsoWCGDUA+WNPmtK/vfPFiyW5c5/GGKZwH6SE8c3nCHAW7mmV8isI
 AT29tfutBenXLSBffpZw==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > It is interesting and suprising to see how people use Emacs in different way.

I don't use Emacs that way.  But I incidentally noticed that when using
Emacs that way I can pop down the completions window without terminating
the minibuffer interaction.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 11:53:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 06:53:07 2020
Received: from localhost ([127.0.0.1]:37145 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knKVP-0007uJ-1e
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 06:53:07 -0500
Received: from mout.gmx.net ([212.227.15.18]:38111)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1knKVN-0007tp-F6
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 06:53:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607601147;
 bh=LksnQepJDH9Gbvx7vTSQ/21N/XdmJyY5Yxj+tTTFwg8=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=MmxA2EDYQYrMaUovoQAibeHFcGY+Eg0gA+BOwDsN5nZkE65KlbLPrAJ25w9GUjNiM
 l2vxQS29hQWHnZk9S58TnOEWa+jP6Q3qcZcf43/RP572ThGhKNfDBlWb27rE/TDk0w
 0D1JIw4hL5dfOBqWh0w4jOTqk01Bfb3t9E0uqg9U=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([212.95.5.249]) by mail.gmx.com (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MA7Ka-1kxno91Fzm-00BZi3; Thu, 10
 Dec 2020 12:52:27 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Jean Louis <bugs@HIDDEN>
References: <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
 <835z5d8lhc.fsf@HIDDEN> <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <X9HctL/WTECDMiD8@HIDDEN>
 <8f775254-65d2-6f3d-4c71-b6f10bb2b278@HIDDEN>
 <X9H1YVXQHzSU0woG@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <a74f9c51-593f-c249-029a-1de9982005dc@HIDDEN>
Date: Thu, 10 Dec 2020 12:52:26 +0100
MIME-Version: 1.0
In-Reply-To: <X9H1YVXQHzSU0woG@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:TIrC625Dn+EJg/rjf8CZ8kKW3PogT3EE+0V8cqXR8PYeVMcj92c
 gcDCrcyDLX58XMcNTlr4msCFXrlWSsS54/gXJf1DM0+r60ShdnwwANQqzJ8OHAqiRFJIWyC
 /9NT0tos1asojU89NfPb8tSZrumjro8JeVtcmEzWmpChrse8eluugqL6s4ZuAd74Zk7wBK6
 jEAhdmgUfPyu4jjYxFCIQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:9Z3ZARewYvE=:XS4qld8Ufm+7dmNiRl7kbl
 yb8PBG9lOvZ+cWXGqSNeiF1ZrlAq0F/d/pa7Xb41vJooZQisHHR/NgVBbIRdNkCDLnNdNi4qs
 6F3IkOa20QmmJBEEBAsapASTqLjQiCUu1wjm72OgoiitgvmRX0YZ6YOTorEDTs4ntAJcmUQMt
 VnVlc+lHeJWnZXPyp7H7haN6RZeqAcQgOgvSDgLEhG7H4x3q+8/S/bP/sf1CXwYM65/4i3F5K
 lXExtN3wMKT1BKxHcD0CI+VU6ALQJDThsH1CzHQex+4QDUn9E8/FOh/YJfjoXIU/EmrTaL6Oq
 s1YW82brQ4sYspRpBpn6/XVZoIiHDVdkiO5kgVShxHMO471zoYzx8aYSccTAaG3Dlo9Htifa6
 eEfYrsc8hBprtLoZfA3xRZiDvCwDRhjlF8c41kZ/+JvSB0GNVPFZ5j4SS0lp0Y8x6Cxepjjon
 x71XXzh5r9zrNki953gd7wMEZHne2lqggyBFJxqU0tVcZJUuf2x1hNRaOdHEWv9JyZ70LsTCi
 r/q9PnGKmGsxtjCnsc/jiEQv+H5pnQ2Q/etcWSEM0Dik9qL/aZ51Eu7a9P8valKVzlg7qewwd
 tn/E232DWMoTyl8zyx6HNmF8riKTQFhAXidZHh1Kofv1x41hzdK7NVJRyg7sqQ7j356dvL9cd
 cLTFiujLkDYn8QrtwxK7yS6X2KL3QhV8UqBRIMS6PrmN8AS6Yrm9DdqKLR/m6RICZoZ1X65R0
 xfyRVbpI5Hjv858+RWKLWnP77PatnAsHeLbHSCsHunmxWS0I7KTbWpfMAp1E2UZK61hJYt4CF
 wGdnVTk+td5rvoajjUuWE89wzBobC5SdIMpLhNc6uXZh0JijrskQ4i2waAaSAUI6oUsua5i4M
 qW2uUjTt94NUyG9tJUAw==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 >> All these scenarios are with customizations.  I'm not experienced enough
 >> to tell whether they (can) happen in practice.
 >
 > Do you refer to standard completion in minibuffer that it may be
 > customized to replace a present window with the completion instead of
 > opening new windows?
 >
 > That would be nice as I would like to avoid those jerks when there are
 > 2 horizontal windows and then third one appears for completion jerking
 > both of them up and narrowing those visible windows to almost
 > invisible rendering both of them unusable.

Doesn't it do that already?  Note that here and elsewhere I'm purely
speculating how application writers and users might tweak things.

 > In that case I would find it useful if the bottom window is
 > temporarily replaced with the completion, without opening the new
 > window for completion. If that would be the case then restoring
 > previous buffer that was there before replacement of window would be
 > necessary and useful.
 >
 > My complain came from those buffers changed by me, user, to something
 > else, that completion never even tackled. I have not even use
 > completion, just minibuffer, and above 2 horizontal windows get
 > restored even though I have not wanted it. By switching to other
 > buffer in those windows user said "I need that other buffer".

These should be already addressed by my earlier patch.  But Juri meant
that we have to handle completions windows separately since otherwise
they may persist.

 > But if the window is replaced with completion, I do not have any
 > window where I would switch the buffer. Or maybe it also works that
 > completion window is switched to something else. Labyrinth.
 >
 > Do you know how to make such setting to open up completion list in
 > such way to replace the bottom window instead of poping up with new
 > window?
 >
 > I cannot find any variable completion*wind

I hope Juri can.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 10:43:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 05:43:49 2020
Received: from localhost ([127.0.0.1]:37115 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knJQL-00064B-2L
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 05:43:49 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:47447)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1knJQH-00063Z-5w
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 05:43:45 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 000000000001E529.000000005FD1FBDA.00001EE4; Thu, 10 Dec 2020 03:43:38 -0700
Date: Thu, 10 Dec 2020 13:16:01 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X9H1YVXQHzSU0woG@HIDDEN>
References: <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
 <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <X9HctL/WTECDMiD8@HIDDEN>
 <8f775254-65d2-6f3d-4c71-b6f10bb2b278@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <8f775254-65d2-6f3d-4c71-b6f10bb2b278@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* martin rudalics <rudalics@HIDDEN> [2020-12-10 12:47]:
> > 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.
> 
> All these scenarios are with customizations.  I'm not experienced enough
> to tell whether they (can) happen in practice.

Do you refer to standard completion in minibuffer that it may be
customized to replace a present window with the completion instead of
opening new windows?

That would be nice as I would like to avoid those jerks when there are
2 horizontal windows and then third one appears for completion jerking
both of them up and narrowing those visible windows to almost
invisible rendering both of them unusable.

In that case I would find it useful if the bottom window is
temporarily replaced with the completion, without opening the new
window for completion. If that would be the case then restoring
previous buffer that was there before replacement of window would be
necessary and useful.

My complain came from those buffers changed by me, user, to something
else, that completion never even tackled. I have not even use
completion, just minibuffer, and above 2 horizontal windows get
restored even though I have not wanted it. By switching to other
buffer in those windows user said "I need that other buffer".

But if the window is replaced with completion, I do not have any
window where I would switch the buffer. Or maybe it also works that
completion window is switched to something else. Labyrinth.

Do you know how to make such setting to open up completion list in
such way to replace the bottom window instead of poping up with new
window?

I cannot find any variable completion*wind





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 10:43:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 05:43:49 2020
Received: from localhost ([127.0.0.1]:37113 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knJQK-000648-Q3
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 05:43:49 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:55963)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1knJQF-00063V-Np
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 05:43:44 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 000000000001E531.000000005FD1FBDE.00001EF7; Thu, 10 Dec 2020 03:43:41 -0700
Date: Thu, 10 Dec 2020 13:21:07 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X9H2k6W4WrMLFjz1@HIDDEN>
References: <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
 <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
 <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* martin rudalics <rudalics@HIDDEN> [2020-12-10 12:47]:
> > What do you type to accept a suggestion?  I can't find a key
> > to accept a suggestion without exiting the minibuffer.
> 
> When I type here
> 
> C-h f set- RET

I just notice I have never in my life used RET there. I always used
TAB and recently C-j

My habit is that RET I consider dangerous or "final choice" so I never
used it to complete. Other completing packages would mess with my data
if I do.

> set-auto-
> 
> When I now type an "m" I get a help window showing me help for
> 'set-auto-mode'.

When I hear the beep or see that I am on the end of line, that is where I press RET. Never before.

It is interesting and suprising to see how people use Emacs in different way.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 09:48:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 04:48:02 2020
Received: from localhost ([127.0.0.1]:37054 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knIYM-0004gK-7B
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 04:48:02 -0500
Received: from mout.gmx.net ([212.227.17.22]:36977)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1knIYK-0004fl-0u
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 04:48:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607593642;
 bh=sjzO+UN0W8dNvYeCx51GolN1Ilqvg0oW6A+1TlpJyvY=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=DKJv8vbeEuUD1b5GviZ+QghLlzUryTlsvXou/ZtAYsdGycRYuvWw8y6WI3RI9Dh+i
 IBEy0OFvmF4Ugy5zedK6KtjF0I/VFUgSGnTnOPzos440n/BWV/kAHtRQ0k5nJ+sQ87
 WFA8wMxVsMf92ixBj5cc1pYfysRHtdH4IxzYr4D0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([46.125.249.102]) by mail.gmx.com (mrgmx104
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0oG5-1jsjaJ297F-00wnZZ; Thu, 10
 Dec 2020 10:47:22 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Juri Linkov <juri@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <87wnxqxdx5.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <73e2a032-d3e9-bc94-2f72-246096ce03cb@HIDDEN>
Date: Thu, 10 Dec 2020 10:47:21 +0100
MIME-Version: 1.0
In-Reply-To: <87wnxqxdx5.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:9Pv1UYmoQMs5iaAK+NYFaqsv3lAzRWrw0xeFZi7iEJ4fdGaMWXM
 aa4KFVoouKCX+sgMwVvFxSd54hWEc2CPIREYXebR7SRPvp4q7fzE8SdY2kACZOck7leRXgu
 py4vfNlYCJmlo8y+mFs3Ut/z1Lm6UwwShTju2fCRm+Gqashfk1fgQqGEgw6HbrCo7ZToczJ
 BaaaI9asI1JU4m58bVqxg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:5oNCBruNxbY=:W8q6yNTIpICY+G2F5Cq320
 6WB2+L3S6RfS9Q/znwPAp5673jVRGiK77bq81XN3yhqfvX/uK0pmSQOUW67jNwrt8wDB44rnG
 7/zkutKUnf5n2xXZKNUyfXgW+2RDvQ0rO/oI9I0GVCGbjiy8XWvxP1CCiRJ3gxu84gvBijs1g
 d7We7Q9+zw1WxNEw0z3+lD6VRMseKhOJ458H9lHAQLPyDxnx4NgnC30QXGQIqdEtXYL6BYlfV
 2dolty2iKmzXH5+k2Du7fghy/IDVbQ0Bw+4WMve+qMqmFoF8OAga1SPb3lCDfT/gcSOZkBJyF
 6HtWGwUK/aTy9cxmA3sApWegwdDhdgN9zAdcVwNbXsoBnfb197ySr7RDPj5Tm9UJ7TT4KWQRC
 BjyLNFVe+vrnugVntugoMCVsU36at9TzQWg4Zg9nf1JMIcAvAFJb3x/ildFHXYTxHVfV1r1Vu
 L1/mXra4ObRoy8UIJyvXFV0mR6Ih3NEPK2H8VsPxXwzeDs6fPlBz+jYMECZelFAnYVTttqPol
 WvGBtODB2mIDFeBBHRZvtaYDIBWvQsP909Y1L60n//u/fW5HpEorKHOCng6xPDu1cKAuZVO7B
 H+T+/6j9fF6k7mzQ5jrIWXDfyKjKhfDTayMk7xIaDku5pFCKs+pBgHOrgxDV+f812h5SW6eCy
 4ukZRW5AvmYhi1E/4sItp8mjQzJZRUXoMNSgGPGwc5D4JRzQ5fPY5WNLkK8stY74Fy4poJrcq
 Px3V5odfkYv9TtzlV4sf4gbC14Tc4FhVX6+5ra8nR86xeltiEggGSNwlr14waXScV1mITcrEG
 W8JSDuzJzDXf6npINi2HKQGRyDyQfPjP2zDQc9vHuhtgzFXE/QszGZIh7BwK0hJDbqcoaQlmw
 2bSIplrHBzjqme99QpDQ==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > What do you type to accept a suggestion?  I can't find a key
 > to accept a suggestion without exiting the minibuffer.

When I type here

C-h f set- RET

I get a completions window with the "set-" prefixed completions.  When I
now type

auto RET

the completions window pops down and the minibuffer window shows

set-auto-

When I now type another RET, the completions window pops up again and
shows the "set-auto-" prefixed completions with the minibuffer showing

set-auto-

When I now type an "m" I get a help window showing me help for
'set-auto-mode'.

So here the pop down works already and I have no idea why it cannot be
extended to the entire completion 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?

The completion mechanism should clean up its traces as soon as it is
finished - either a choice has been made or it has been aborted: This
can mean to clean up windows or frames, size back a minibuffer window or
remove a pop up menu or a dialogue box.  But I hardly ever use that
mechanism so I cannot tell how it works (or should work) in practice.

In either case 'exit-minibuffer' is too late.  It must be either the
caller of completions - just in case it wants to, for example, reuse the
present window for refining the list of completions - or the called
which might be more noisy with windows popping up and down.  And I
suppose that completions are not invoked from minibuffer interactions
alone ...

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

Yes.  But IMO that should be done _before_ reading from the minibuffer
interaction finished.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 09:47:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 04:47:14 2020
Received: from localhost ([127.0.0.1]:37050 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knIXZ-0004ew-Uy
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 04:47:14 -0500
Received: from mout.gmx.net ([212.227.17.21]:54769)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1knIXW-0004eh-Vz
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 04:47:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607593590;
 bh=VA3lU2qizoHsfYRrsWl7Ov1Gg9U6NQ8oVNyJs//DkLE=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=FypXu/KWx1Pvynqu49W69sR70QZhAZl/RfNrqlFHHTUnl5CqCghYdjXN63q+0m+pc
 xTorNuHo9LrPyhce4eIJzi5sccgfkb7uDiAeb7NY+8o7UBlxRvmGmUReMl1KkEJTAP
 x4gu8URcKqKGmU3OPAG/6yHwCsw5urchRlyYiklo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([46.125.249.102]) by mail.gmx.com (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MbAgq-1kG9de2E5g-00bbFs; Thu, 10
 Dec 2020 10:46:30 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Jean Louis <bugs@HIDDEN>
References: <87eek1fvgf.fsf@HIDDEN> <X85bhc/D4Xsat7Vv@HIDDEN>
 <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
 <835z5d8lhc.fsf@HIDDEN> <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
 <X9HctL/WTECDMiD8@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <8f775254-65d2-6f3d-4c71-b6f10bb2b278@HIDDEN>
Date: Thu, 10 Dec 2020 10:46:28 +0100
MIME-Version: 1.0
In-Reply-To: <X9HctL/WTECDMiD8@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:4/16QPrGXMRnXxG2vGBrnV+tmfbsuTUppJb0ghMPND4/be68Dq8
 O4buHBPm8olQHZtdslTiOS7WUzrXpyx3deFyue5D8Sy8CsYlvzSIXT7JHe0WDAb6Gpw4Gvj
 XH82ADDZKHuCMMg7AwkE0ju4Shuu9yCvPvs07cbKIKr9/msliJyuUE1Oja8vyarEDTc57Vp
 LmIzmwTvQ87bpEuk1hKfg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:JoXRHQG+S0c=:0RsuQgDgDbGTzyEifNPjJo
 cHeTwGJSNgNBu3tqcTBAV0Upq07Tk+WfxrEy8fgItmwJd7rAi3ka4wHxFu/uAvrBsHdYq4PC0
 6LHNPXJPuYxyFN4lxH8zw4Hg9FhHiPytTCcyYsg7lguO/EAvBkT4hse5bEli894/78tknJOl8
 aT7+BFBwbeqOeBIr0/eze0AQb4eY928bZQcvlch6udriaJ65cDPez6aBZp/zB0cDbEqzSsJrv
 0zNcDqA9FRfPVUnM6nf4ClLPczMPRnm92RC/BLGWot3cj4ihp1ZfMaCYQjrF480HHCtYZxjTa
 du+6iG7vSAwhMX+dFfo6FeON8BTlml92/djP2mVYW3wMc1JYw1tS5SYl67ieAgrQ0hGcuIKMR
 /gApgLVeFoRM9LpcnOmJf9Ky4mELAXAd8QuKnSdD1SQ2HyBXEySvCWdvPW7Gqq0S6ybSaaZgL
 zv5UIhtmr+h4Otajqi2bKuAbSPY1e93vqhoGejGM9eA5SJnobnBXmJh8+7LeSTvTIZFmWgfNB
 2B/wP5xOp3wm2jNWDBNneI9uvcOtwHk4phpASDCl/wKrkJUDrP27K65A8RH+jea4WrKaUtxrO
 cCaxC3n1Dhal6PHt2W1dOh3qiquuaXVBmGeE3JVDAxaRHRDTk/5U0S/sHz6VGxc8L4RQxsxON
 1B9jkKN3mkZ0Wf3VaVkeu9MOlWrw8qSb2Mra48n1FV7SGykSz7dkunr9X6Zr8XvYx1yd9PJJ9
 ZMLszICjDnJk6l97+8oOPMN7bSPEZ5S/9Mpdkwd6+w3ilhld5I5WfNbKPF2q0FoEf/ynim3Wz
 IFwCmXL11lj37ASvbLRh4g3TnoOKwNI+I+paoMPvomubMkp8zZNdvBVBqSmI4gFwY6LHjpJVt
 En/a4IqCPIip4hAqwKOw==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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

All these scenarios are with customizations.  I'm not experienced enough
to tell whether they (can) happen in practice.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 08:34:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 03:34:31 2020
Received: from localhost ([127.0.0.1]:36963 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knHPD-0002qu-B7
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:34:31 -0500
Received: from relay11.mail.gandi.net ([217.70.178.231]:50031)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1knHPB-0002qa-Vj
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:34:30 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay11.mail.gandi.net (Postfix) with ESMTPSA id E0EA2100009;
 Thu, 10 Dec 2020 08:34:21 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Organization: LINKOV.NET
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
Date: Thu, 10 Dec 2020 10:32:54 +0200
In-Reply-To: <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN> (martin rudalics's
 message of "Thu, 10 Dec 2020 08:44:57 +0100")
Message-ID: <87wnxqxdx5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 08:32:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 03:32:58 2020
Received: from localhost ([127.0.0.1]:36952 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knHNi-0002nu-Fg
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:32:58 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:54503)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1knHNh-0002n5-4I
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:32:57 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 000000000001E00D.000000005FD1DD38.0000132F; Thu, 10 Dec 2020 01:32:55 -0700
Date: Thu, 10 Dec 2020 11:30:44 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X9HctL/WTECDMiD8@HIDDEN>
References: <87eek1fvgf.fsf@HIDDEN> <X85bhc/D4Xsat7Vv@HIDDEN>
 <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
 <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
 <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* martin rudalics <rudalics@HIDDEN> [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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 07:45:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 02:45:39 2020
Received: from localhost ([127.0.0.1]:36844 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knGdv-0001Y0-0u
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 02:45:39 -0500
Received: from mout.gmx.net ([212.227.17.22]:51791)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1knGdt-0001Xl-MH
 for 45072 <at> debbugs.gnu.org; Thu, 10 Dec 2020 02:45:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607586299;
 bh=Tn03fPbQQLoUvtsCoD/HUe4iNupYHHBa8Zdhf8gw0x8=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=Ry/zDfKhclQOvdd2AljbbcVGRyryKmpshhll66nELWTYi2cZv/M8+8cJWaEwY6yiS
 eXk4nHlNovuR6mbv/IjO1/veRs/wRmo0j80QIlq/6MKzwi9depCqSrhisUij1l8cy9
 u4VvQVn2VU2nywrXQu9zCG2XNCrgzFvc+INTUVco=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([46.125.249.102]) by mail.gmx.com (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MSbx3-1kgMiY0t2H-00SyCw; Thu, 10
 Dec 2020 08:44:59 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Juri Linkov <juri@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <877dpqzx3o.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <57c673d0-e6e7-120d-8893-92b02ab1530e@HIDDEN>
Date: Thu, 10 Dec 2020 08:44:57 +0100
MIME-Version: 1.0
In-Reply-To: <877dpqzx3o.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:OztriwD1OQ2ZIEpk6h6/zDZy7Taoct7XScxiWbeLTYURcQYMmGG
 h3/ftSjCNj7TykHlhS4LKjmW8TOe+Glv6tuGEZ9Q4mO9+ZKkq2DksObL5u9wykD1MxNPKvA
 I27VBUdiJ62GOMfpKcsbrh2I92jEXikIjNc2LHKeQpUvtRubTS7FHcFw0l0q5ijOX1NvmKl
 Jc9zpI6UnHZPExvv9rVpA==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:bv2JINlO7Gs=:2JyHnO/tEhgiN9QF7K5PSI
 b739N231pOUIHroCTGLIIcgtELhc8vWJDVFNhea2NOQWJOL8H/ZfKknue6dxaZVNUnPOi9e7Z
 W2fyO1iolWLWP94N2xlU5xQrbgYM96v4+Bvis2TiTr1uaIbrknlUlbclKq1NmwEfhPFkykSLr
 l+b6zLx0OG3YpWhfxW69Ngo7id9VNtNtUg4ohHRvopytsvGc5KLHLAoplKwiQVxmrhakNBlQb
 vqVRiZOQIrGevx1BuoHCFPyzwFQ5gB7vPPxJhQmQooKnidpwjK364CwWB8M/7N/0ShL2da6OG
 bo6SDSJ4XOccMRPo7kU/oI9GcQxb6TJIP4lhzcetnvLeswG76wN2hhLOSLhH++JrhnN5Pa6RT
 5DpeKZKS9XvZ8ydK5LfweMTNEfX1VDATY5zbW/0HMF5jgy+IJUUMvKnVXoYxngjNVmwRmJ3tb
 sMaakmcA9u2DRIckBuIaF2Kx8Q7cQLL5K2LOqcfXg7DxelWwyPopCsPnWuAVNvK9auTPmyuVk
 aBbZ9RUB/TUOeELKElaSuYgCX3rZJJ9hhyEV9upYg4kNK19LLBHP601VlHqQG2WKBQSKvE30+
 wD9aY0AFr3sTwDDk3BMWpNJIaWdC9ApXH737faOR0aj7ScYnZbopGDo4K4yJLyvEzTFEmZ5Gv
 AgmG40uOW775iG9Fz3tibdr3FXEIdUyj6SbpAiYlq26UBYpRen0+qeoxalxrd73qFRIzmNTwK
 S5c1kDJeOPqoRnXTYfJLnR1fgmrJAHZY8/e7kTbQp6GXE8CFimOqoX4kZdpkaYe+VgTNYc67o
 vdjGB5SFqBihMr7bNu4hVZ6jM4TRuJJtH/IXUbkGYMC6O6QqXLvoxNY0tG9sCgvH45pVY0KLC
 G7nwtG5lOi0O5KxgbGvg==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 19:22:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 14:22:15 2020
Received: from localhost ([127.0.0.1]:36136 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kn52V-0004DE-6q
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 14:22:15 -0500
Received: from relay11.mail.gandi.net ([217.70.178.231]:58381)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kn52U-0004Ck-DF
 for 45072 <at> debbugs.gnu.org; Wed, 09 Dec 2020 14:22:14 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay11.mail.gandi.net (Postfix) with ESMTPSA id 57BB3100005;
 Wed,  9 Dec 2020 19:22:05 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Organization: LINKOV.NET
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
Date: Wed, 09 Dec 2020 21:11:39 +0200
In-Reply-To: <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN> (martin rudalics's
 message of "Wed, 9 Dec 2020 10:34:01 +0100")
Message-ID: <877dpqzx3o.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 15:17:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 10:17:20 2020
Received: from localhost ([127.0.0.1]:35717 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kn1DT-00089f-Pf
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 10:17:19 -0500
Received: from mout.gmx.net ([212.227.15.19]:59559)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1kn1DS-00084D-8y
 for 45072 <at> debbugs.gnu.org; Wed, 09 Dec 2020 10:17:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607527000;
 bh=BWOiQp8tICIGUd8fltIokc6ooP/Xhozq2azEmQqheGs=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=AKtc6nzkOQp3tn9oRC3org01J47yRqP80LEZTnFv7pW29pfIoJ74pc/rGGaPHI/71
 GHuDAaJqnJ1s/ezc9CvvLb5g7O3916m41E6Cu4Rl5o/sWxpDyVgZ7qyPpQ3/1M1i9B
 /8GwzDkL7UWEEA/aeKN/ozPoYMTph/0c1skWbiz8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([212.95.5.220]) by mail.gmx.com (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M6UZv-1kl6SP2Vyb-006v3d; Wed, 09
 Dec 2020 16:16:40 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Jean Louis <bugs@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
 <X9ChwTgNWpjE8pmV@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <532737ad-8326-8f07-766f-780838a4718e@HIDDEN>
Date: Wed, 9 Dec 2020 16:16:39 +0100
MIME-Version: 1.0
In-Reply-To: <X9ChwTgNWpjE8pmV@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:WzIGgSicst0Nm9BpQibMiov2o+gBYfhk4/8DV0wu0yAG3hAXjpv
 AXyv0sQqtz148HmXzOj35lEWi5IECKvyA2rkwotCT4tDMBrPHjpLDcdIoH4esSz4fxeUfHz
 O/r5Bb0+t6atLl3IKGoCsUaOfIaq0VHWTmGGNz0UEpC3/GPMC25QxKEWiUPl2HEKT6Kyy+Q
 rySK6/YnSsTDzNOML/HAQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:QnuEGnC89KM=:Pw6Kvd9zUAO8n0J6O5OXSq
 fCdDO0oua4no7rtx4hn3DmnyeGGUIG11hSjEnVEQZzaVXA6p5XU9g/UimV7BTpiEKDhKdCf7K
 t/q5+BXnHHFYaxqROB8OXXiKRU7vuJmH/kwlg04iD/ufZu7thQRnpigHyGhRm2tQv8hVvvuUW
 cMmOAYj2uW+/I0hQREzWZlDCrZWi5opZAmPg56oUfetoZMtMFtW9ivcuz8Xy2RZ0CWpbc0aWx
 fSAtN/Uv5akQ9CC73GI1I7bzCWCrJ2mVEMsMwK3gEiV3juaF+9M4bXbIXGiBllvXDtX7iblN1
 u1gqqVy6yvud7S1PFh9zGU+CAG6Qa2K3T/mUQEnoJEf1fbRLnxbk7ZLzsIdzRe3/mXiEcSO4z
 Oxn2/9i/jlUD3p46dQRa4QSCSJVN6/4LQOsw5Dx/xBePH2t0iPsDuXZ4iENDuNoPGq1RlK5C9
 pmx+9nhA4kX5mPb40907btJidQq/Mk5vrjBTHINOzqaA6loNxIBYWZDOh6IS81HZ0hkgjf25v
 eCHOG6hsNi0iul0C0sGVwxGqNq0sYnxjUb/0UcTBxhmnTJLYZx1xZkVgM3/o+Qr0BXZV3Bpiz
 /bgXr1bBHyFvcVctNT7pEKdkdnWK5XhKmpJNv361sI49s4fFOIuOO2qoq/7/t4wxK8klgmyMY
 iZ0q0JItiTSXXdjqEVXGo5YYwKMjFyzU6sxS3Lj5/9x+TQ6+PlWvIRHW8EGVlpUAkNBreCsSQ
 ge+eV4AaUZyN7N4apaexZ6zHYxGpsYeqR5PFUbPdmHccFIB8HLsidO44IAKdTRW490Ngcya8g
 ixp2Fx7fXy1k9LO9+rnwTmINHRDCOzVbEZ6UKtZzidMDUyPJj8UBwcgl50SiDEUhKZY9MXhbq
 mR04yDZN7zOcBR+o2wvOkvyOJtLRzyhUgoLTwuOhw=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: >> 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 p [...] 
 Content analysis details:   (2.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [212.95.5.220 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [212.227.15.19 listed in wl.mailspike.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [212.227.15.19 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (rudalics[at]gmx.at)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  >> 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 p [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [212.95.5.220 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [212.227.15.19 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [212.227.15.19 listed in wl.mailspike.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (rudalics[at]gmx.at)
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

 >> 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.
 >
 > I am not sure if my case was understood, let me use artist-mode:
 >
 >   +----------------------------+
 >   |                            |
 >   | I was changing this        |
 >   | during minibuffer edit     |
 >   +----------------------------+
 >   | I was also changing this   |
 >   | during minibuffer editd    |		-
 >   |                    	      |
 >   +----------------------------+
 >   +----------------------------+
 >
 > If I would have larger screen I would put all necessary buffers around
 > and use them to get references for minibuffer input. Instead I was
 > switching buffers in upper windows during minibuffer edit. It is not
 > related to shrinking or completions. My minibuffer was not completing
 > rather just reading string. During editing I would go up and switch to
 > one image or other. I was in the loop of minibuffer editing of
 > multiple coordinates. Upon each editing the already set images in
 > upper windows would switch back where minibuffer was invoked
 > initially.
 >
 > That forces me to use outside program to keep pictures on screen when
 > required and makes editing less useful.

Have you tried my latest patch?

The problem Juri raised is that Emacs itself might pop up or reuse other
windows in order to display text related to the minibuffer interaction
and I think that such windows should be deleted or get their buffer
restored by the interaction itself (using 'quit-window' probably).

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 14:03:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 09:03:04 2020
Received: from localhost ([127.0.0.1]:33113 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kn03c-0003bM-Mk
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 09:03:04 -0500
Received: from static.rcdrun.com ([95.85.24.50]:50443)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kn03b-0003as-76
 for 45072 <at> debbugs.gnu.org; Wed, 09 Dec 2020 09:03:03 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C000B.000000005FD0D910.00001438; Wed, 09 Dec 2020 14:02:56 +0000
Date: Wed, 9 Dec 2020 13:06:57 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X9ChwTgNWpjE8pmV@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
 <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  * martin rudalics <rudalics@HIDDEN> [2020-12-09 12:34]: >
 > 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 > > con [...] 
 Content analysis details:   (1.1 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.1 DATE_IN_PAST_03_06     Date: is 3 to 6 hours before Received: date
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, 45072 <at> debbugs.gnu.org, larsi@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.1 (/)

* martin rudalics <rudalics@HIDDEN> [2020-12-09 12:34]:
> > 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.

I am not sure if my case was understood, let me use artist-mode:

 +----------------------------+
 |                            |
 | I was changing this        |
 | during minibuffer edit     |
 +----------------------------+
 | I was also changing this   |
 | during minibuffer editd    |		-
 |                    	      |
 +----------------------------+
 +----------------------------+

If I would have larger screen I would put all necessary buffers around
and use them to get references for minibuffer input. Instead I was
switching buffers in upper windows during minibuffer edit. It is not
related to shrinking or completions. My minibuffer was not completing
rather just reading string. During editing I would go up and switch to
one image or other. I was in the loop of minibuffer editing of
multiple coordinates. Upon each editing the already set images in
upper windows would switch back where minibuffer was invoked
initially.

That forces me to use outside program to keep pictures on screen when
required and makes editing less useful.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 09:34:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 04:34:44 2020
Received: from localhost ([127.0.0.1]:32803 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmvrw-0003Aa-GI
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 04:34:44 -0500
Received: from mout.gmx.net ([212.227.15.19]:52841)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1kmvrr-00039x-T9
 for 45072 <at> debbugs.gnu.org; Wed, 09 Dec 2020 04:34:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607506443;
 bh=Ei/xGrRN4hKKYJ1C5ojTnAO5nOoj849lT2ntlpZkgJ8=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=XTwgJBMeD39Cw951teaXAC3KzwoaiRsg/Nmk2OxBvYQIyrvlMuYMrvc6YuCqsyHjo
 pIuK4dIISqgM/e7OK/6ZkIo3JkAym0qdJZwjJTndk5gst0mKwS5a1oWM2BeW2dCFIT
 Qlk01YFApas23au+kUeFCaRHzVYl2RJykwYVI1Ds=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([212.95.5.125]) by mail.gmx.com (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mwwdl-1jufLc07BL-00yS6W; Wed, 09
 Dec 2020 10:34:03 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Juri Linkov <juri@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87pn3k87tx.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <d400db9b-bfc5-5a50-ad92-b306cdb008ba@HIDDEN>
Date: Wed, 9 Dec 2020 10:34:01 +0100
MIME-Version: 1.0
In-Reply-To: <87pn3k87tx.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:0djN3EUre6wzRyGgHHh1aY7fsnZnxvmPCmdP/Tt98ziOwwwF5DY
 fC2BaBZJmujZN7MMqShK9dQFKTPD6kPwpxA3d3skl7mqttGOPdHBYlCPHWWDExHqI3aAo0V
 gFpLiSQnxK+IEjM8Ntuk8+5HTSKlk3jzbN+EO8/2AnVrOWrzhfVury7/ezYOzzHwT2QyMza
 jwCWkSESDiQlRMgreGwrA==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:ZUMJAGMuJJA=:qC8ihsxbvBL30fKLROUgHc
 Cnwtn0DSayglR4KXOTfYf14YkAKu+QBltAlpWq0qEeOOViKTGOqCEapv1CS9jMjO97eqwM1LP
 uF9s8hSLbMZTuRsS6okmqNl5sOshZJ2sv0h8BhYbBW8SY16W4Q5fH3EBffK0eLyTIEJ6KEARC
 t2uy/G3d9OKt/pLytKLXfpExaFXFUzuI5Vow4YKD6REh9JXOOYlRt7iVgukkoyo1mECcKAeyV
 HJE6wv9hROQcA0MRIA1z2chQSiwL4/WIhI/HjWLDqjiBVfcr0Cksmzge9Y4z1jgjE/IQypT2s
 bZ2Nd/kubiQRIUrj1SqZFY8oH3mCbrfZJojek1K2YzIskZCv3UpU3rNBnQqsfKKKgaSdKJTaU
 S5xOXzYoQjkDTzeA68yI7CdXSZN5xdrmsOEkKqicAeLGZlvM6vhgIiSUSKjw+awG0bbyUHajQ
 wdckxzNQeUlUlgScUmQrOKHyMcHakiJJHp78FHXQOYAZQqacDX3o4DEkXYxKSEBrzbEMW9HrM
 ET7s/WVzE/r9XxbnePK9LpppMibC63Rxo7/xOJkVGMpRGxcv2Dr3+QAJ/mK/LVa+1Nl7h0yKo
 ZMspu5S+Eo5qxpoe7v207A4uOxyvDYMfuakca8SN/cW0Wt1ieI5uvj/lI9qmKjWrYuvpsoAI/
 23hL+NnnRZcZ0r0qpa9kY021Zcskz1HoGLJNj/K7qiOgPqjwchJwYGOG4xciuvLSGLA6kC3Gc
 /VkI75EzARWNzVvUr8/aMBBZmFHnA8/YfYHHu/STvoNBplmNzP6qpe8TMqelAv2ZBE84TvoT4
 nQl0IFwVK21+6ofG3IamuK93tgUiUK+FOuArHH2x4MIXfti8UVPTBNw5UhC7JbljyqJuu8V+5
 yoCu154BtWxrfgl3MUmjwLgcdefHGYA2Pi96vwpshD09zCrlE0CZxI5VhCZbIS
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 09:34:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 04:34:09 2020
Received: from localhost ([127.0.0.1]:32792 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmvrM-00039J-SB
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 04:34:09 -0500
Received: from mout.gmx.net ([212.227.15.18]:46967)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1kmvrK-00038m-HW
 for 45072 <at> debbugs.gnu.org; Wed, 09 Dec 2020 04:34:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607506408;
 bh=tK26AXfTtFwFNC+XtExGYY/OAAaCdYTnyKs5ynR6QzY=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=XjC/Ktz1Mabv9E25DZNcZDYYL5ps1/9hnvqoov2S8cLbnpwOoV94Z+rvRfbdi6S9n
 qmMPvK1mfmd0RhZB6wGd5P7ndc4DsVWboqxPgbv+2nx7xiobCnUa2hdln0h41znUQS
 csduEc6g1p94oVGDkOOgzkFZbq+ztiA+EktjuO5c=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([212.95.5.125]) by mail.gmx.com (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M6UZv-1kkyqP2Wi1-006w1P; Wed, 09
 Dec 2020 10:33:28 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Eli Zaretskii <eliz@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN> <87lfe8jsok.fsf@HIDDEN>
 <83h7ow70ty.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <7a7c3ef0-619d-cd76-a4e4-040009e33d75@HIDDEN>
Date: Wed, 9 Dec 2020 10:33:26 +0100
MIME-Version: 1.0
In-Reply-To: <83h7ow70ty.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------EE7172677FC90A372510258B"
Content-Language: en-US
X-Provags-ID: V03:K1:rK0wQdE/OZP8SzJAj+bS0UBT01lIx92qOh0+Emwyqm40Z6GJwfJ
 ltew1Oh/FupP5Ik38JId87K9q8slv/nVN5ebgbSg8ICCoeMtFfyO+OQC6dfw0MJTxy12vWZ
 hTMT9U0HFfAdDHh6Vp0R4RlCZljYAW8r1TrYNfy+F3oqr37IFe46X3p9Vsm0Gq6mTNYUOv9
 Lhk/Jbau4ANqCvnfYwGPQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:mpJIWqUGtpc=:uFyNi5UdFMK6T4ZmyBsN1I
 E2/f0LWjzcJffOG1hQW7Uz7YKGQM4RQPXBVfuwL5Jt1zy9QVtsc9G+faUDvg65GAQAg7I7gO8
 TVZ8qVp7mdiBqLnWFa4lQoVBC8ELY635Uu5CAIiXWONtLgfwQqNzcoNKSqMsnjaDxuyfoGIKa
 Hm4+BgyQLxqxjf3DuzYyt/5cX0LAT1XhqutQl1u/MtxbBISITG6PIl+puf9JDr5m0G01WhuML
 q4HLKI+7OXe4l3P7pFbNs29QPclIW6R1D4FWWH0+LwdZp2F1aw6N19NCJZWfnQDmcYdxyNO6g
 29LWKWYFozC5jc9WDSG7zAr8L9UJpEsbLAcCP9JS3iDkOSYRHVpa+2YTHYQJpxZ72kKDm5qyd
 y/DSs+tQJNn0BfLm3NebLRs/MMKOskhxgZjb/wOngbuKhW//iiKX0vq8twFMhB4p1vO7/Sqfq
 tIR37PJBElXZVXfpY/J1CUoWSa1QSm3JJ+cTG9mmCjP5DAYjY+jki1tAaEewpXC80nOVJeHA6
 9X3jL7Neq3WEeH/oJh7ahJLTeh+3+fAAXBYXbk1wA33B3FqYs7gc9vqBwqUC4mWHoqqMEUp7/
 vn+zpOYDyEbAhCKGUvmXy9KZJ0SqpjS9S869JQ45AWpTiFHu0duZ82/3dztzsCrB3l4EazJ1v
 lDPKMJZ0+KIP8l2coJuCMKr1Zp6w5Ooxgk8htoGlxJITHZXUuk1RHLyIEBZqZE0SaYWQbj0JZ
 dIjXn+hm/nFrjrWDcY7eQh7ptgvD7f5LtYBrZLbBLIXQVT+SjvJ4sAXrV6ZsQUMh6V/7Sg6Qo
 kbSN7LpV3nMEIw3TD7jw6QyM8Wacdqr+pi2dZJNsXOE6g5PEd9h62L7rfPrufRxnRg1jz/pqu
 h++70c4QxSmQ2LDWJfcw==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: bugs@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

This is a multi-part message in MIME format.
--------------EE7172677FC90A372510258B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

 > Yes.  But maybe read-from-minibuffer-restore-windows would be even
 > better.

And `read-minibuffer-restore-windows' would be even shorter.  Attached.

martin

--------------EE7172677FC90A372510258B
Content-Type: text/x-patch;
 name="read-minibuffer-restore-windows.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="read-minibuffer-restore-windows.diff"

=2D-- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -458,6 +458,19 @@ Text from Minibuffer
 list is used in the prompt.
 @end defun

+@defvar read-minibuffer-restore-windows
+If this option is non-@code{nil} (the default), getting input from the
+minibuffer will restore, on exit, the window configurations of the frame
+where the minibuffer was entered from and, if it is different, the frame
+that owns the minibuffer window.  This means that if, for example, a
+user splits a window while getting input from the minibuffer on the same
+frame, that split will be undone when exiting the minibuffer.
+
+If this option is @code{nil}, no such restorations are done.  Hence, the
+window split mentioned above will persist after exiting the minibuffer.
+@end defvar
+
+
 @node Object from Minibuffer
 @section Reading Lisp Objects with the Minibuffer
 @cindex minibuffer input, reading lisp objects
=2D-- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -500,19 +500,21 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, =
Lisp_Object prompt,

   record_unwind_protect_void (choose_minibuf_frame);

-  record_unwind_protect (restore_window_configuration,
-                         Fcons (Qt, Fcurrent_window_configuration (Qnil))=
);
+  if (read_minibuffer_restore_windows)
+    record_unwind_protect (restore_window_configuration,
+			   Fcons (Qt, Fcurrent_window_configuration (Qnil)));

   /* If the minibuffer window is on a different frame, save that
      frame's configuration too.  */
   mini_frame =3D WINDOW_FRAME (XWINDOW (minibuf_window));
-  if (!EQ (mini_frame, selected_frame))
+
+  if (read_minibuffer_restore_windows && !EQ (mini_frame, selected_frame)=
)
     record_unwind_protect (restore_window_configuration,
 			   Fcons (/* Arrange for the frame later to be
-                                     switched back to the calling
-                                     frame. */
-                                  Qnil,
-                                  Fcurrent_window_configuration (mini_fra=
me)));
+				     switched back to the calling
+				     frame. */
+				  Qnil,
+				  Fcurrent_window_configuration (mini_frame)));

   /* If the minibuffer is on an iconified or invisible frame,
      make it visible now.  */
@@ -2186,6 +2188,15 @@ syms_of_minibuf (void)
 uses to hide passwords.  */);
   Vread_hide_char =3D Qnil;

+  DEFVAR_BOOL ("read-minibuffer-restore-windows", read_minibuffer_restore=
_windows,
+	       doc: /* Non-nil means restore window configurations on exit from =
minibuffer.
+If this is non-nil (the default), reading input with the minibuffer will
+restore, on exit, the window configurations of the frame where the
+minibuffer was entered from and, if it is different, the frame that owns
+the associated minibuffer window.  If this is nil, no such restorations
+are done.  */);
+  read_minibuffer_restore_windows =3D true;
+
   defsubr (&Sactive_minibuffer_window);
   defsubr (&Sset_minibuffer_window);
   defsubr (&Sread_from_minibuffer);

--------------EE7172677FC90A372510258B--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 19:21:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 14:21:01 2020
Received: from localhost ([127.0.0.1]:59822 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmiXl-0004bW-Hd
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 14:21:01 -0500
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:56881)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kmiXj-0004bA-AM
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 14:21:00 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id A03C1240005;
 Tue,  8 Dec 2020 19:20:51 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Organization: LINKOV.NET
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
Date: Tue, 08 Dec 2020 21:15:06 +0200
In-Reply-To: <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN> (martin rudalics's
 message of "Tue, 8 Dec 2020 09:09:28 +0100")
Message-ID: <87pn3k87tx.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

>> The defaults are definitely fine, IMO.  But if you want very much to
>> have an opt-in behavior to disable restoring of the window
>> configuration of the frame, I won't object to such an option.
>
> Patch attached, just in case.  99% untested.

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*.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 16:14:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 11:14:44 2020
Received: from localhost ([127.0.0.1]:59316 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmfdU-0007wr-BR
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 11:14:44 -0500
Received: from static.rcdrun.com ([95.85.24.50]:40021)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmfdS-0007wd-Bc
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 11:14:42 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C1B08.000000005FCFA66C.00003A24; Tue, 08 Dec 2020 16:14:35 +0000
Date: Tue, 8 Dec 2020 19:14:12 +0300
From: Jean Louis <bugs@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X8+mVK22RJlhytdh@HIDDEN>
References: <87eek1fvgf.fsf@HIDDEN> <X85bhc/D4Xsat7Vv@HIDDEN>
 <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
 <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87lfe8jsok.fsf@HIDDEN>
 <9286deee-b549-0441-9571-e7d712c5fdd5@HIDDEN>
 <X8+UoL4bp4jtsIp/@protected.rcdrun.com> <83eek0701j.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <83eek0701j.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: * Eli Zaretskii <eliz@HIDDEN> [2020-12-08 19:09]: > > Date:
 Tue, 8 Dec 2020 17:58:40 +0300 > > From: Jean Louis <bugs@HIDDEN> >
 > Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@gnu. [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 45072
Cc: rudalics@HIDDEN, larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * Eli Zaretskii <eliz@HIDDEN> [2020-12-08 19:09]: > > Date:
    Tue, 8 Dec 2020 17:58:40 +0300 > > From: Jean Louis <bugs@HIDDEN> >
   > Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@gnu. [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* Eli Zaretskii <eliz@HIDDEN> [2020-12-08 19:09]:
> > Date: Tue, 8 Dec 2020 17:58:40 +0300
> > From: Jean Louis <bugs@HIDDEN>
> > Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
> >   45072 <at> debbugs.gnu.org
> > 
> > I would prefer by default not to switch windows for me as if I am user
> > and switched the other buffer why would I need it automatically back?
> > I switched it because I do not need it.
> > 
> > Please understand how it is to work in a loop in minibuffer, many
> > coordinates have to be entered carefully and various maps consulted,
> > and then even though buffers were switched there and back on each new
> > invocation of minibuffer prompt all those buffers go away.
> > 
> > >From the view point of having user control, I would rather have that
> > option turned off by default.
> 
> I understand your POV, but we cannot possibly change such a
> long-standing behavior by default.  It must start as an opt-in
> behavior.  Later, when enough people tried it and said they'd like it
> to be the default, we might start thinking about making it the
> default.

I totally and generally agree on the approach not to change
default. It is just opinion, I would not change defaults as it would
influence many.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 16:08:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 11:08:58 2020
Received: from localhost ([127.0.0.1]:59308 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmfXu-0007nq-Dk
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 11:08:58 -0500
Received: from eggs.gnu.org ([209.51.188.92]:37190)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kmfXr-0007nb-Ar
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 11:08:57 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:53270)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kmfXl-0002hU-AE; Tue, 08 Dec 2020 11:08:49 -0500
Received: from [176.228.60.248] (port=3863 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kmfXk-0007JO-Ey; Tue, 08 Dec 2020 11:08:49 -0500
Date: Tue, 08 Dec 2020 18:08:40 +0200
Message-Id: <83eek0701j.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Jean Louis <bugs@HIDDEN>
In-Reply-To: <X8+UoL4bp4jtsIp/@protected.rcdrun.com> (message from Jean Louis
 on Tue, 8 Dec 2020 17:58:40 +0300)
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87lfe8jsok.fsf@HIDDEN>
 <9286deee-b549-0441-9571-e7d712c5fdd5@HIDDEN>
 <X8+UoL4bp4jtsIp/@protected.rcdrun.com>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45072
Cc: rudalics@HIDDEN, larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 8 Dec 2020 17:58:40 +0300
> From: Jean Louis <bugs@HIDDEN>
> Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
>   45072 <at> debbugs.gnu.org
> 
> I would prefer by default not to switch windows for me as if I am user
> and switched the other buffer why would I need it automatically back?
> I switched it because I do not need it.
> 
> Please understand how it is to work in a loop in minibuffer, many
> coordinates have to be entered carefully and various maps consulted,
> and then even though buffers were switched there and back on each new
> invocation of minibuffer prompt all those buffers go away.
> 
> >From the view point of having user control, I would rather have that
> option turned off by default.

I understand your POV, but we cannot possibly change such a
long-standing behavior by default.  It must start as an opt-in
behavior.  Later, when enough people tried it and said they'd like it
to be the default, we might start thinking about making it the
default.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:51:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 10:51:53 2020
Received: from localhost ([127.0.0.1]:59275 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmfHN-0005FS-0U
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:51:53 -0500
Received: from eggs.gnu.org ([209.51.188.92]:60852)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kmfHK-0005FF-Ph
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:51:51 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52805)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kmfHF-0004Ge-3f; Tue, 08 Dec 2020 10:51:45 -0500
Received: from [176.228.60.248] (port=2827 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kmfHD-0003ja-Bz; Tue, 08 Dec 2020 10:51:43 -0500
Date: Tue, 08 Dec 2020 17:51:37 +0200
Message-Id: <83h7ow70ty.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <87lfe8jsok.fsf@HIDDEN> (message from Lars Ingebrigtsen on Tue, 
 08 Dec 2020 15:09:15 +0100)
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN> <87lfe8jsok.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45072
Cc: rudalics@HIDDEN, bugs@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Lars Ingebrigtsen <larsi@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>,  Jean Louis <bugs@HIDDEN>,
>   45072 <at> debbugs.gnu.org
> Date: Tue, 08 Dec 2020 15:09:15 +0100
> 
> Looks good to me, but I'd revert the logic, as "negative" variables have
> a tendency to be misunderstood.  That is, call the variable
> `read-from-minibuffer-restore' and default it to t instead.

Yes.  But maybe read-from-minibuffer-restore-windows would be even
better.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:13:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 10:13:48 2020
Received: from localhost ([127.0.0.1]:59174 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmegW-0008Rj-6R
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:13:48 -0500
Received: from eggs.gnu.org ([209.51.188.92]:48248)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kmegV-0008RX-4g
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:13:47 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51757)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kmegM-0007Al-J9; Tue, 08 Dec 2020 10:13:40 -0500
Received: from [176.228.60.248] (port=4356 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kmeg9-0005Hk-CA; Tue, 08 Dec 2020 10:13:26 -0500
Date: Tue, 08 Dec 2020 17:13:19 +0200
Message-Id: <83v9dc72ls.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: rms@HIDDEN
In-Reply-To: <E1kmVcX-0005IE-PM@HIDDEN> (message from Richard
 Stallman on Tue, 08 Dec 2020 00:33:05 -0500)
Subject: Re: bug#45072: 28.0.50;
 Emacs switches other buffer back uncontrollably, if other window's
 buffer is changed by user during minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN>
 <87eek1fvgf.fsf@HIDDEN> <X85bhc/D4Xsat7Vv@HIDDEN>
 <83eek18ref.fsf@HIDDEN> <E1kmVcX-0005IE-PM@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45072
Cc: larsi@HIDDEN, bugs@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Richard Stallman <rms@HIDDEN>
> Cc: bugs@HIDDEN, larsi@HIDDEN, 45072 <at> debbugs.gnu.org
> Date: Tue, 08 Dec 2020 00:33:05 -0500
> 
>   > My recommendation is not to "abuse" the recursive editing; the ELisp
>   > manual rightfully warns against that, albeit indirectly.
> 
> Should we make this warning more direct
> so that people notice it more?

The user manual has this in the section about recursive editing:

     In general, we try to minimize the use of recursive editing levels in
  GNU Emacs.  This is because they constrain you to go back in a
  particular order—from the innermost level toward the top level.  When
  possible, we present different activities in separate buffers so that
  you can switch between them as you please.  Some commands switch to a
  new major mode which provides a command to switch back.  These
  approaches give you more flexibility to go back to unfinished tasks in
  the order you choose.

Suggestions to add to this text something more direct are welcome.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:05:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 10:05:00 2020
Received: from localhost ([127.0.0.1]:59144 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmeXz-0008Cg-NR
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:05:00 -0500
Received: from static.rcdrun.com ([95.85.24.50]:49579)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmeXu-0008BV-Hh
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:04:54 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C1B02.000000005FCF9615.0000315A; Tue, 08 Dec 2020 15:04:53 +0000
Date: Tue, 8 Dec 2020 17:58:40 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X8+UoL4bp4jtsIp/@protected.rcdrun.com>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87lfe8jsok.fsf@HIDDEN>
 <9286deee-b549-0441-9571-e7d712c5fdd5@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <9286deee-b549-0441-9571-e7d712c5fdd5@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  * martin rudalics <rudalics@HIDDEN> [2020-12-08 17:47]: >
 > Looks good to me, but I'd revert the logic, as "negative" variables have
 > > a tendency to be misunderstood. That is, call the variable > > [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 45072
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * martin rudalics <rudalics@HIDDEN> [2020-12-08 17:47]: >
   > Looks good to me, but I'd revert the logic, as "negative" variables have
    > > a tendency to be misunderstood. That is, call the variable > > [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* martin rudalics <rudalics@HIDDEN> [2020-12-08 17:47]:
> > Looks good to me, but I'd revert the logic, as "negative" variables have
> > a tendency to be misunderstood.  That is, call the variable
> > `read-from-minibuffer-restore' and default it to t instead.
> 
> Coming from the frame/window department I'm usually against defaulting
> options to non-nil because nil-valued and absent parameters behave the
> same way.  But I have no problems doing what you propose.  Let's see if
> anyone really wants such an option.

I would prefer by default not to switch windows for me as if I am user
and switched the other buffer why would I need it automatically back?
I switched it because I do not need it.

Please understand how it is to work in a loop in minibuffer, many
coordinates have to be entered carefully and various maps consulted,
and then even though buffers were switched there and back on each new
invocation of minibuffer prompt all those buffers go away.

From the view point of having user control, I would rather have that
option turned off by default.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:04:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 10:04:59 2020
Received: from localhost ([127.0.0.1]:59142 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmeXz-0008CY-9j
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:04:59 -0500
Received: from static.rcdrun.com ([95.85.24.50]:48741)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmeXt-0008BW-JJ
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:04:54 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C1AF1.000000005FCF9614.00003154; Tue, 08 Dec 2020 15:04:52 +0000
Date: Tue, 8 Dec 2020 17:58:40 +0300
From: Jean Louis <bugs@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X8+UoL4bp4jtsIp/@protected.rcdrun.com>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87lfe8jsok.fsf@HIDDEN>
 <9286deee-b549-0441-9571-e7d712c5fdd5@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <9286deee-b549-0441-9571-e7d712c5fdd5@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  * martin rudalics <rudalics@HIDDEN> [2020-12-08 17:47]: >
 > Looks good to me, but I'd revert the logic, as "negative" variables have
 > > a tendency to be misunderstood. That is, call the variable > > [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 45072
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * martin rudalics <rudalics@HIDDEN> [2020-12-08 17:47]: >
   > Looks good to me, but I'd revert the logic, as "negative" variables have
    > > a tendency to be misunderstood. That is, call the variable > > [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* martin rudalics <rudalics@HIDDEN> [2020-12-08 17:47]:
> > Looks good to me, but I'd revert the logic, as "negative" variables have
> > a tendency to be misunderstood.  That is, call the variable
> > `read-from-minibuffer-restore' and default it to t instead.
> 
> Coming from the frame/window department I'm usually against defaulting
> options to non-nil because nil-valued and absent parameters behave the
> same way.  But I have no problems doing what you propose.  Let's see if
> anyone really wants such an option.

I would prefer by default not to switch windows for me as if I am user
and switched the other buffer why would I need it automatically back?
I switched it because I do not need it.

Please understand how it is to work in a loop in minibuffer, many
coordinates have to be entered carefully and various maps consulted,
and then even though buffers were switched there and back on each new
invocation of minibuffer prompt all those buffers go away.

From the view point of having user control, I would rather have that
option turned off by default.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:04:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 10:04:54 2020
Received: from localhost ([127.0.0.1]:59136 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmeXu-0008Bu-2k
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:04:54 -0500
Received: from static.rcdrun.com ([95.85.24.50]:48741)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmeXr-0008BW-6F
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:04:52 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C1AF1.000000005FCF960B.0000311D; Tue, 08 Dec 2020 15:04:43 +0000
Date: Tue, 8 Dec 2020 17:18:23 +0300
From: Jean Louis <bugs@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X8+LLzpU9Uw6gf0l@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87lfe8jsok.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <87lfe8jsok.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  * Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-08 17:10]: >
 martin rudalics <rudalics@HIDDEN> writes: Thank you all! Jean 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 45072
Cc: martin rudalics <rudalics@HIDDEN>, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-08 17:10]: >
    martin rudalics <rudalics@HIDDEN> writes: Thank you all! Jean 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-08 17:10]:
> martin rudalics <rudalics@HIDDEN> writes:

Thank you all!

Jean




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:04:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 10:04:54 2020
Received: from localhost ([127.0.0.1]:59132 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmeXt-0008Br-LS
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:04:54 -0500
Received: from static.rcdrun.com ([95.85.24.50]:49579)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmeXr-0008BV-1X
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 10:04:52 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C1B02.000000005FCF960C.0000311F; Tue, 08 Dec 2020 15:04:43 +0000
Date: Tue, 8 Dec 2020 17:18:23 +0300
From: Jean Louis <bugs@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X8+LLzpU9Uw6gf0l@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
 <87lfe8jsok.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <87lfe8jsok.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  * Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-08 17:10]: >
 martin rudalics <rudalics@HIDDEN> writes: Thank you all! Jean 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 45072
Cc: martin rudalics <rudalics@HIDDEN>, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-08 17:10]: >
    martin rudalics <rudalics@HIDDEN> writes: Thank you all! Jean 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-08 17:10]:
> martin rudalics <rudalics@HIDDEN> writes:

Thank you all!

Jean




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 14:47:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 09:47:50 2020
Received: from localhost ([127.0.0.1]:57076 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmeHO-00056t-LI
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 09:47:50 -0500
Received: from mout.gmx.net ([212.227.15.15]:39517)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1kmeHM-00056g-UL
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 09:47:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607438831;
 bh=rmzrFEWDGQjmhmAbEIPcRo45pAoqZ3n8zq9WWjBax1Y=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=i4jR2jwX1r4RUV1y+X9ihD167kiFUs1/IDtMzu46oClnnGNTLkekVpWaYfnQgmp0l
 Y+M0nXGEO4J8EH0qQZiHiF8gGS16bCvgOmwGTXtv+v+Sn9Vpx+D62e0sTCpPbCzPqy
 0cihu+zwCUf0RD5oDqrbI8q3/qZiG8umUAOgZgaA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([46.125.249.58]) by mail.gmx.com (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MS3ir-1kaw8C1ZKF-00TVEu; Tue, 08
 Dec 2020 15:47:11 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Lars Ingebrigtsen <larsi@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN> <87lfe8jsok.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <9286deee-b549-0441-9571-e7d712c5fdd5@HIDDEN>
Date: Tue, 8 Dec 2020 15:47:10 +0100
MIME-Version: 1.0
In-Reply-To: <87lfe8jsok.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:vQRE8a9Ov4T/Ai5efgirVJKb283mjZ3VCvmcrY/X6WO4WeQoV/0
 PKPyuGarg9Oqk5B1wsfTDxFfjpW1cJRNZu0MZMtTn+6GAsfTHIwSQ8pj59/avppYlwTAAmS
 3eiSwywbvcEtXmPykGi6ZB2a8b6RFg4SEmEJNVh+fKMXyNeAlm08uun+jkMNNCbrWgrIMst
 q9AS4+R2OYK9V2D9B7J+g==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:F8yXLx1G/O8=:/pB1g+Bti7wFJURoK2a9b5
 fu+DllKzwsefWcVDbk6yoYLs2xkfhe2GGkQswbw8yK2o2fjIRi9nCnbIiF6Zp2pvbxuFON/Gn
 8ASSqjlKDc2Ya505eoFP4og0VElAc3Ajf2/XXj/7vtwqhD9iDTzLOf9xB9SYKh3m3iZgmb7db
 mn+J+onTemxEsH1YwpehUAw/W3hmGEUvSgdsfVZYdEypc2yUsRjDdSq4qX06PTJ1TZu+0YKay
 QnN3XdGAPtfQvHTMcLxL1iKPYso0IZ7+1qwlnNqcI03iUV1gkxjk8734zq43I8wIDGLwuSVtR
 1HJMuTZEGohQ7tWFBHSin70/wPfbACVigx+Km2TNTxQQTK5sngEy2RJNx5lROjMqfrcCs0yYZ
 EykJcDj/PNB1zGUThdVHOEI0aZDQYo0F/nVrgtvvJFmGVdHqjd3b3Hr12xyBN2f6Yj4gBWlGo
 DRYzUPyZPjlESlZYf38rD3B6qBHFx79bSeR9/EQtL48k37rhzX4Pikwgo4VV0QpoYcSZ34KR0
 lRpE/dD4Ckd+0+3grjWXbzEHH0MeToajA4rQmqVB0YvjchGPE4lpdwP14CIJrBGs8e8YvGxK8
 wQighxKMEXT+Wz4gw20CkUABGNmsFYUAj1PgCfEH6ZnSMI8i7YdvqpZtH02rOPu+3njOCAdDW
 ABaLMNZ6ZMKoQ7gGJkZSPGpsQLZlWH2TyPWRHLBRbF8u4MH6YmBsl8f40bmfkSGaFfkt8Hfu9
 9WoxY2yUFraK2j9GDEpV3OXZZZfq6oiag+H7HcSABY9WxZHPKQeUYMR9DLSPF7ZXxmIAU+TSs
 aWHuyvsLt2gKUj0GqlvSeaicDANZ7nkWJPXqMI50bTD4BQW+ZMJntHPDFwGmAGNlv8bbm+JaG
 49TOdqFlO5KSAGfPogkA==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > Looks good to me, but I'd revert the logic, as "negative" variables have
 > a tendency to be misunderstood.  That is, call the variable
 > `read-from-minibuffer-restore' and default it to t instead.

Coming from the frame/window department I'm usually against defaulting
options to non-nil because nil-valued and absent parameters behave the
same way.  But I have no problems doing what you propose.  Let's see if
anyone really wants such an option.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 14:09:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 09:09:30 2020
Received: from localhost ([127.0.0.1]:56993 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmdgH-0008Kg-QE
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 09:09:30 -0500
Received: from quimby.gnus.org ([95.216.78.240]:50796)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1kmdgG-0008KU-7K
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 09:09:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=FiPEVcQXFQj41zA26YulVIxOfE7wwrtZLXxDfXbIDWg=; b=AS+WkoTbFTu8qmYMOUgnCOy3+v
 Oa+AJKk8aHnSIdj2nbWysfiseniFHVh7lBS4QlZg/tZcl2MnmnLJRXSjOyvU3N3e+7ukUUsmpCNgE
 HPRxXIHB92Xk4oSfYsLYAEyEbZ31jTHjUMpUfiIwnW0INCQNuX39wQWz+zCj5+Lopq0I=;
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1kmdg4-0002mE-BZ; Tue, 08 Dec 2020 15:09:21 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
 <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
X-Now-Playing: Act 4's _Circuit City_: "No More Wires"
Date: Tue, 08 Dec 2020 15:09:15 +0100
In-Reply-To: <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN> (martin rudalics's
 message of "Tue, 8 Dec 2020 09:09:28 +0100")
Message-ID: <87lfe8jsok.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  martin rudalics <rudalics@HIDDEN> writes: > Patch attached, 
 just in case. 99% untested. [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: Eli Zaretskii <eliz@HIDDEN>, Jean Louis <bugs@HIDDEN>,
 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

martin rudalics <rudalics@HIDDEN> writes:

> Patch attached, just in case.  99% untested.

[...]

> +  DEFVAR_BOOL ("read-from-minibuffer-no-restore", read_from_minibuffer_no_restore,
> +	       doc: /* Non-nil means `read-from-minibuffer' does not restore window configurations.
> +If this is nil, `read-from-minibuffer' will restore, on exit, the window
> +configurations of the frame where it was called from and, if it is
> +different, the frame that owns the minibuffer window.  If this is
> +non-nil, no such restorations are done.  */);
> +  read_from_minibuffer_no_restore = false;

Looks good to me, but I'd revert the logic, as "negative" variables have
a tendency to be misunderstood.  That is, call the variable
`read-from-minibuffer-restore' and default it to t instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 08:10:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 03:10:09 2020
Received: from localhost ([127.0.0.1]:56463 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmY4W-0003rB-Gg
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 03:10:08 -0500
Received: from mout.gmx.net ([212.227.15.15]:54811)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1kmY4T-0003qQ-Vo
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 03:10:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1607414968;
 bh=4YQ74zYFmSCce/nsWcovrDfo1MgZrIef7TeCqfbPtZE=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=OADN8fLYpCzsUIcmHkG2PeaL+frthV9QaIf0kL9hKBIuIib/gQwgoheRXkNKLLRiC
 q41bJreXAuHnXJd5coH5jtdjnLBMedGzNb4vHQDvPKOpy/qmDMcHevEQYDcuog/xNM
 391WPWAWfLvkTiLQNj6l461VQhKvRGPtxHrGBHcM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.100] ([46.125.249.58]) by mail.gmx.com (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N3bSj-1k3tv93ImJ-010h6p; Tue, 08
 Dec 2020 09:09:28 +0100
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during minibuffer
 editing
To: Eli Zaretskii <eliz@HIDDEN>, Jean Louis <bugs@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <c2425dfb-972d-67d7-f76d-2120b0529ac0@HIDDEN>
Date: Tue, 8 Dec 2020 09:09:28 +0100
MIME-Version: 1.0
In-Reply-To: <835z5d8lhc.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------6BC1C4F906D49E33E409D905"
Content-Language: en-US
X-Provags-ID: V03:K1:Iv5m4e/Nch95P5egOkKaCmQe8t3VhWhXv+ccEuovj6J7qTLdUgD
 56o43OyxdumpvKbP9nmUn2doEx/Y/wr7D6TLbSV5RZsJN5Yq2vsSxKWQ+bHc63UYNbQBm5v
 /6nNfGtpwxBQzEFHr3WtoAZ2qFW6rYanwOU0ZOS76UvHpasbFsdGjjobKDPWjFcFtg/dlnE
 ahQDMg3Q14QLuUDgJbCmQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:ZIY420JEFrY=:U5shya8KcPbqgNzwIXLqJI
 ADHc7qbJeF+DtrvmWZgL6skcfZjgLyx5WXnXPg/UuXLKKJN4wE25wDEl2cifjqb+y74qYj1uG
 t5TKypqBMajzEFHLEVwcL2kKu3gJCiHIx7ekWPBzt6GzMm3FAW6+TMx54lXrUP4+7Xi2at0Nz
 zxKzA9U0VSBSvSh91+maE6rDQAF5kcItq2qCBh+/7IBQZVKyW/YPJ/Z+tA80hd7tSx6SNTZMZ
 7OWTm+4fweo2gJCXSXdLoNiUhGR0aV41F/xSU10EFZJrRdmu57jXaj+3psIt0aHCEYI7T9ha/
 ZnmfeVT4D0IJmds86IFzIRZniw9t0p4OaUuWRI21ugIyX+FcqSJXlYLiuaW3KW6Eg2k1/bnVL
 2YYjn9NGPHZczDDArozj2JPw8l0uuIlQwrgEKRT4GfAcWzb5A/MCDIqXXqanw+GcNbZ0nf247
 IkNhXV5kaORfLOS9ntPXAnonQRo1XfdmRI+xMAHTP6eImH3E4+QSi5sG3OYCRQB7nQGLtXOps
 4IcU+ZYD1PRPhEYBKUCW5mgNcxi0+DYwJpErNCqdjjFUHpuqWqpby2h8xV0G69nKBJtELfovC
 jdrOlfnQMvVE+X0BIoj5NIOYORzOAgBjQbVl8i/a9mrdeGvVec+b2Cq4A33l11hkeN92ZuKBQ
 J7jEu67yYXJgtDe9zo7MgZvbBJ8k7f4vX1zcnEp9DitDVdtgsP3Ko+ezZzV1yOqX0bX/O4frF
 KMo7agdKluynWQu9wejH54h9ZVQjqIVLMYLVgg4ztitZ2GtVE8xnxOZbgsespfTMSNxmdVFyq
 rq1jWsnEvAQQ+2F2pUgiqr2300eqO05XhmuhJd/mwEjoe1rHks3fiiK96CAYBB0Z7bv2J60+P
 YlkmIhj+7dUZMydegy4Q==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45072
Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

This is a multi-part message in MIME format.
--------------6BC1C4F906D49E33E409D905
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

 > The defaults are definitely fine, IMO.  But if you want very much to
 > have an opt-in behavior to disable restoring of the window
 > configuration of the frame, I won't object to such an option.

Patch attached, just in case.  99% untested.

martin

--------------6BC1C4F906D49E33E409D905
Content-Type: text/x-patch;
 name="minibuf.c.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="minibuf.c.diff"

diff --git a/src/minibuf.c b/src/minibuf.c
index fc3fd92a88..9874e71a2f 100644
=2D-- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -500,19 +500,21 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, =
Lisp_Object prompt,

   record_unwind_protect_void (choose_minibuf_frame);

-  record_unwind_protect (restore_window_configuration,
-                         Fcons (Qt, Fcurrent_window_configuration (Qnil))=
);
+  if (!read_from_minibuffer_no_restore)
+    record_unwind_protect (restore_window_configuration,
+			   Fcons (Qt, Fcurrent_window_configuration (Qnil)));

   /* If the minibuffer window is on a different frame, save that
      frame's configuration too.  */
   mini_frame =3D WINDOW_FRAME (XWINDOW (minibuf_window));
-  if (!EQ (mini_frame, selected_frame))
+
+  if (!read_from_minibuffer_no_restore && !EQ (mini_frame, selected_frame=
))
     record_unwind_protect (restore_window_configuration,
 			   Fcons (/* Arrange for the frame later to be
-                                     switched back to the calling
-                                     frame. */
-                                  Qnil,
-                                  Fcurrent_window_configuration (mini_fra=
me)));
+				     switched back to the calling
+				     frame. */
+				  Qnil,
+				  Fcurrent_window_configuration (mini_frame)));

   /* If the minibuffer is on an iconified or invisible frame,
      make it visible now.  */
@@ -2186,6 +2188,14 @@ syms_of_minibuf (void)
 uses to hide passwords.  */);
   Vread_hide_char =3D Qnil;

+  DEFVAR_BOOL ("read-from-minibuffer-no-restore", read_from_minibuffer_no=
_restore,
+	       doc: /* Non-nil means `read-from-minibuffer' does not restore win=
dow configurations.
+If this is nil, `read-from-minibuffer' will restore, on exit, the window
+configurations of the frame where it was called from and, if it is
+different, the frame that owns the minibuffer window.  If this is
+non-nil, no such restorations are done.  */);
+  read_from_minibuffer_no_restore =3D false;
+
   defsubr (&Sactive_minibuffer_window);
   defsubr (&Sset_minibuffer_window);
   defsubr (&Sread_from_minibuffer);

--------------6BC1C4F906D49E33E409D905--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 05:33:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 00:33:16 2020
Received: from localhost ([127.0.0.1]:56299 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmVch-0008Ca-W9
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 00:33:16 -0500
Received: from eggs.gnu.org ([209.51.188.92]:37636)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1kmVcg-0008CO-9j
 for 45072 <at> debbugs.gnu.org; Tue, 08 Dec 2020 00:33:14 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:44053)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <rms@HIDDEN>)
 id 1kmVca-0003E6-Oc; Tue, 08 Dec 2020 00:33:08 -0500
Received: from rms by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <rms@HIDDEN>)
 id 1kmVcX-0005IE-PM; Tue, 08 Dec 2020 00:33:06 -0500
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <83eek18ref.fsf@HIDDEN> (message from Eli Zaretskii on Mon, 07
 Dec 2020 19:20:08 +0200)
Subject: Re: bug#45072: 28.0.50;
 Emacs switches other buffer back uncontrollably, if other window's
 buffer is changed by user during minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN>
 <87eek1fvgf.fsf@HIDDEN> <X85bhc/D4Xsat7Vv@HIDDEN>
 <83eek18ref.fsf@HIDDEN>
Message-Id: <E1kmVcX-0005IE-PM@HIDDEN>
Date: Tue, 08 Dec 2020 00:33:05 -0500
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45072
Cc: larsi@HIDDEN, bugs@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rms@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My recommendation is not to "abuse" the recursive editing; the ELisp
  > manual rightfully warns against that, albeit indirectly.

Should we make this warning more direct
so that people notice it more?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 19:48:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 07 14:48:13 2020
Received: from localhost ([127.0.0.1]:55550 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmMUX-0006RC-EG
	for submit <at> debbugs.gnu.org; Mon, 07 Dec 2020 14:48:13 -0500
Received: from static.rcdrun.com ([95.85.24.50]:43521)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmMUU-0006Qv-Cq
 for 45072 <at> debbugs.gnu.org; Mon, 07 Dec 2020 14:48:12 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C0007.000000005FCE86F3.00005F73; Mon, 07 Dec 2020 19:48:03 +0000
Date: Mon, 7 Dec 2020 22:45:16 +0300
From: Jean Louis <bugs@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X86GTHgO+M7U5EAf@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
 <X855Hs/j6qRLDxD3@HIDDEN> <835z5d8lhc.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <835z5d8lhc.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: * Eli Zaretskii <eliz@HIDDEN> [2020-12-07 22:28]: > > Date:
 Mon, 7 Dec 2020 21:49:02 +0300 > > From: Jean Louis <bugs@HIDDEN> >
 > Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org > > > > > My recommend [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 45072
Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * Eli Zaretskii <eliz@HIDDEN> [2020-12-07 22:28]: > > Date:
    Mon, 7 Dec 2020 21:49:02 +0300 > > From: Jean Louis <bugs@HIDDEN> >
   > Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org > > > > > My recommend [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* Eli Zaretskii <eliz@HIDDEN> [2020-12-07 22:28]:
> > Date: Mon, 7 Dec 2020 21:49:02 +0300
> > From: Jean Louis <bugs@HIDDEN>
> > Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org
> > 
> > > My recommendation is not to "abuse" the recursive editing; the ELisp
> > > manual rightfully warns against that, albeit indirectly.  If you
> > > frequently need ti switch away of the minibuffer without exiting it, I
> > > suggest to use a separate frame for your excursions: when exiting the
> > > minibuffer, Emacs only restores the windows on the frame where you
> > > entered the minibuffer (assuming you aren't using minibuffer-only
> > > frames).
> > 
> > If there is logic and reason fine, we close this?
> 
> The defaults are definitely fine, IMO.  But if you want very much to
> have an opt-in behavior to disable restoring of the window
> configuration of the frame, I won't object to such an option.

I think I am only one and is not necessary. I can setup environment
better like you said. I was editing geographic coordinates one after
the other and one cannot make a mistake there and I need to watch
pictures while editing which are in various buffers.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 19:28:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 07 14:28:20 2020
Received: from localhost ([127.0.0.1]:55515 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmMBH-0005vj-W8
	for submit <at> debbugs.gnu.org; Mon, 07 Dec 2020 14:28:20 -0500
Received: from eggs.gnu.org ([209.51.188.92]:59486)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kmMBD-0005vS-NQ
 for 45072 <at> debbugs.gnu.org; Mon, 07 Dec 2020 14:28:18 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:34320)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kmMB8-0003ss-Da; Mon, 07 Dec 2020 14:28:10 -0500
Received: from [176.228.60.248] (port=3675 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kmMB6-0008GV-2Y; Mon, 07 Dec 2020 14:28:09 -0500
Date: Mon, 07 Dec 2020 21:27:59 +0200
Message-Id: <835z5d8lhc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Jean Louis <bugs@HIDDEN>
In-Reply-To: <X855Hs/j6qRLDxD3@HIDDEN> (message from Jean Louis
 on Mon, 7 Dec 2020 21:49:02 +0300)
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN>
 <83eek18ref.fsf@HIDDEN> <X855Hs/j6qRLDxD3@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45072
Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 7 Dec 2020 21:49:02 +0300
> From: Jean Louis <bugs@HIDDEN>
> Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org
> 
> > My recommendation is not to "abuse" the recursive editing; the ELisp
> > manual rightfully warns against that, albeit indirectly.  If you
> > frequently need ti switch away of the minibuffer without exiting it, I
> > suggest to use a separate frame for your excursions: when exiting the
> > minibuffer, Emacs only restores the windows on the frame where you
> > entered the minibuffer (assuming you aren't using minibuffer-only
> > frames).
> 
> If there is logic and reason fine, we close this?

The defaults are definitely fine, IMO.  But if you want very much to
have an opt-in behavior to disable restoring of the window
configuration of the frame, I won't object to such an option.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 18:53:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 07 13:53:25 2020
Received: from localhost ([127.0.0.1]:55494 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmLdS-00056K-Sg
	for submit <at> debbugs.gnu.org; Mon, 07 Dec 2020 13:53:25 -0500
Received: from static.rcdrun.com ([95.85.24.50]:35973)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmLdG-00055y-Jq
 for 45072 <at> debbugs.gnu.org; Mon, 07 Dec 2020 13:53:21 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C0003.000000005FCE7A0F.000055B4; Mon, 07 Dec 2020 18:53:03 +0000
Date: Mon, 7 Dec 2020 21:49:02 +0300
From: Jean Louis <bugs@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X855Hs/j6qRLDxD3@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN> <87eek1fvgf.fsf@HIDDEN>
 <X85bhc/D4Xsat7Vv@HIDDEN> <83eek18ref.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <83eek18ref.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * Eli Zaretskii <eliz@HIDDEN> [2020-12-07 20:20]: > > Date:
    Mon, 7 Dec 2020 19:42:45 +0300 > > From: Jean Louis <bugs@HIDDEN> >
   > Cc: 45072 <at> debbugs.gnu.org > > > > Why is that default there? > > [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* Eli Zaretskii <eliz@HIDDEN> [2020-12-07 20:20]:
> > Date: Mon, 7 Dec 2020 19:42:45 +0300
> > From: Jean Louis <bugs@HIDDEN>
> > Cc: 45072 <at> debbugs.gnu.org
> > 
> > Why is that default there?
> 
> Because minibuffer input can easily create one or more additional
> windows, e.g. to show the completion candidates, and we don't want
> that to be left on display when you exit the minibuffer.
> 
> My recommendation is not to "abuse" the recursive editing; the ELisp
> manual rightfully warns against that, albeit indirectly.  If you
> frequently need ti switch away of the minibuffer without exiting it, I
> suggest to use a separate frame for your excursions: when exiting the
> minibuffer, Emacs only restores the windows on the frame where you
> entered the minibuffer (assuming you aren't using minibuffer-only
> frames).

If there is logic and reason fine, we close this?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 17:20:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 07 12:20:29 2020
Received: from localhost ([127.0.0.1]:55370 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmKBZ-0004uC-J5
	for submit <at> debbugs.gnu.org; Mon, 07 Dec 2020 12:20:29 -0500
Received: from eggs.gnu.org ([209.51.188.92]:55028)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kmKBW-0004tw-4C
 for 45072 <at> debbugs.gnu.org; Mon, 07 Dec 2020 12:20:28 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:59983)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kmKBQ-0006Ni-NG; Mon, 07 Dec 2020 12:20:20 -0500
Received: from [176.228.60.248] (port=3750 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kmKBP-0006mO-UK; Mon, 07 Dec 2020 12:20:20 -0500
Date: Mon, 07 Dec 2020 19:20:08 +0200
Message-Id: <83eek18ref.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Jean Louis <bugs@HIDDEN>
In-Reply-To: <X85bhc/D4Xsat7Vv@HIDDEN> (message from Jean Louis
 on Mon, 7 Dec 2020 19:42:45 +0300)
Subject: Re: bug#45072: 28.0.50;
 Emacs switches other buffer back uncontrollably, if other window's
 buffer is changed by user during minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN>
 <87eek1fvgf.fsf@HIDDEN> <X85bhc/D4Xsat7Vv@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45072
Cc: larsi@HIDDEN, 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 7 Dec 2020 19:42:45 +0300
> From: Jean Louis <bugs@HIDDEN>
> Cc: 45072 <at> debbugs.gnu.org
> 
> Why is that default there?

Because minibuffer input can easily create one or more additional
windows, e.g. to show the completion candidates, and we don't want
that to be left on display when you exit the minibuffer.

My recommendation is not to "abuse" the recursive editing; the ELisp
manual rightfully warns against that, albeit indirectly.  If you
frequently need ti switch away of the minibuffer without exiting it, I
suggest to use a separate frame for your excursions: when exiting the
minibuffer, Emacs only restores the windows on the frame where you
entered the minibuffer (assuming you aren't using minibuffer-only
frames).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 16:43:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 07 11:43:14 2020
Received: from localhost ([127.0.0.1]:55259 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmJbW-00060y-6z
	for submit <at> debbugs.gnu.org; Mon, 07 Dec 2020 11:43:14 -0500
Received: from static.rcdrun.com ([95.85.24.50]:42193)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kmJbU-00060l-Gi
 for 45072 <at> debbugs.gnu.org; Mon, 07 Dec 2020 11:43:13 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C0006.000000005FCE5B99.0000383F; Mon, 07 Dec 2020 16:43:05 +0000
Date: Mon, 7 Dec 2020 19:42:45 +0300
From: Jean Louis <bugs@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
Message-ID: <X85bhc/D4Xsat7Vv@HIDDEN>
References: <86eek3hvu5.fsf@HIDDEN>
 <87eek1fvgf.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <87eek1fvgf.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  * Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-07 19:11]: >
 Jean Louis <bugs@HIDDEN> writes: > > > At that point one may see that
 the window's buffer switched back to > > what it was previously. U [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 45072
Cc: 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  * Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-07 19:11]: >
    Jean Louis <bugs@HIDDEN> writes: > > > At that point one may see that
    the window's buffer switched back to > > what it was previously. U [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* Lars Ingebrigtsen <larsi@HIDDEN> [2020-12-07 19:11]:
> Jean Louis <bugs@HIDDEN> writes:
> 
> > At that point one may see that the window's buffer switched back to
> > what it was previously. User's workflow is disturbed.
> 
> Yes, when exiting a recursive edit, Emacs will (try to) restore the
> window configuration in place when the recursive edit was entered.
> 
> This can be somewhat confusing -- I can see why somebody would want to
> avoid that.  Is there some user option to control this?  I have a brief
> look, but didn't find anything.  If not, would it make sense to add one?

What makes sense is not to have that by default and let users switch
windows as they wish. If I have horizontally split windows:

1
--
2
--
minibuffer

and I change window 1 to 4, upon completing minibuffer window 1
becomes 4. I cannot see why. I need to consult 2-3 buffers while using
minibuffer.

Why is that default there?





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at 45072 <at> debbugs.gnu.org:


Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 16:10:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 07 11:10:53 2020
Received: from localhost ([127.0.0.1]:55094 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmJ6D-0000re-5p
	for submit <at> debbugs.gnu.org; Mon, 07 Dec 2020 11:10:53 -0500
Received: from quimby.gnus.org ([95.216.78.240]:38962)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1kmJ6B-0000rN-9J
 for 45072 <at> debbugs.gnu.org; Mon, 07 Dec 2020 11:10:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1GYap5cuZRK83f7cAOW9HiDdxCiX6wXpqc1AXweJ7vg=; b=eTeS/b+DqH4EB2Qs1YRWFVhjj2
 gcmsAgKpctqThSlDX0+E+uDYExd4q9NSrtQKpcG1qdPskmsLZKDcATD5Qgs4oDPknLbasfq1iAaJn
 lu9UVPCcPPl3D+XesA4DQatoc0rNXQec6Ni00s9JyQlbFh/i+5qjUkCql48aWbx/lufo=;
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1kmJ61-0007Qp-Cd; Mon, 07 Dec 2020 17:10:44 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Jean Louis <bugs@HIDDEN>
Subject: Re: bug#45072: 28.0.50; Emacs switches other buffer back
 uncontrollably, if other window's buffer is changed by user during
 minibuffer editing
References: <86eek3hvu5.fsf@HIDDEN>
X-Now-Playing: Alva Noto's _Xerrox Vol. 04_: "Xerrox Calypsoid 1"
Date: Mon, 07 Dec 2020 17:10:40 +0100
In-Reply-To: <86eek3hvu5.fsf@HIDDEN> (Jean Louis's message of
 "Sun, 06 Dec 2020 17:07:14 +0300")
Message-ID: <87eek1fvgf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Jean Louis <bugs@HIDDEN> writes: > At that point one
 may see that the window's buffer switched back to > what it was previously.
 User's workflow is disturbed. Yes, when exiting a recursive edit, Emacs will
 (try to) restore the window configuration in place when the recursive edit
 was entered. 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45072
Cc: 45072 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jean Louis <bugs@HIDDEN> writes:

> At that point one may see that the window's buffer switched back to
> what it was previously. User's workflow is disturbed.

Yes, when exiting a recursive edit, Emacs will (try to) restore the
window configuration in place when the recursive edit was entered.

This can be somewhat confusing -- I can see why somebody would want to
avoid that.  Is there some user option to control this?  I have a brief
look, but didn't find anything.  If not, would it make sense to add one?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 6 Dec 2020 14:08:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 06 09:08:47 2020
Received: from localhost ([127.0.0.1]:49226 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kluiU-0004LP-Pc
	for submit <at> debbugs.gnu.org; Sun, 06 Dec 2020 09:08:47 -0500
Received: from lists.gnu.org ([209.51.188.17]:47128)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <admin@HIDDEN>) id 1kluiT-0004LG-8i
 for submit <at> debbugs.gnu.org; Sun, 06 Dec 2020 09:08:45 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:56504)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <admin@HIDDEN>)
 id 1kluiT-0001Dw-1c
 for bug-gnu-emacs@HIDDEN; Sun, 06 Dec 2020 09:08:45 -0500
Received: from static.rcdrun.com ([95.85.24.50]:47947)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <admin@HIDDEN>)
 id 1kluiQ-0007EI-W4
 for bug-gnu-emacs@HIDDEN; Sun, 06 Dec 2020 09:08:44 -0500
Received: from localhost ([::ffff:197.157.0.57])
 (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by static.rcdrun.com with ESMTPSA
 id 00000000002C0007.000000005FCCE5C8.00007EEA; Sun, 06 Dec 2020 14:08:07 +0000
From: Jean Louis <bugs@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 28.0.50; Emacs switches other buffer back uncontrollably, if other
 window's buffer is changed by user during minibuffer editing
X-Hashcash: 1:20:201206:bug-gnu-emacs@HIDDEN::z56ZZ1G29TzEWvY1:00000000000000000000000000000000000000001pE4
Date: Sun, 06 Dec 2020 17:07:14 +0300
Message-ID: <86eek3hvu5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=95.85.24.50;
 envelope-from=admin@HIDDEN; helo=static.rcdrun.com
X-Spam_score_int: 17
X-Spam_score: 1.7
X-Spam_bar: +
X-Spam_report: (1.7 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_SBL_CSS=3.335,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Description of the bug: When I have action to repeatedly be
 asked something from mini buffer, then I often move cursor from mini buffer
 to some other buffer. Normally screen is split into two or more buffer. If
 I move the ot [...] 
 Content analysis details:   (2.4 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [197.157.0.57 listed in zen.spamhaus.org]
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=admin%40protected.rcdrun.com; ip=209.51.188.17; r=debbugs.gnu.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
 mail domains are different
 -2.3 RCVD_IN_DNSWL_MED      RBL: Sender listed at https://www.dnswl.org/,
 medium trust [209.51.188.17 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H4      RBL: Very Good reputation (+4)
 [209.51.188.17 listed in wl.mailspike.net]
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Description of the bug: When I have action to repeatedly be
    asked something from mini buffer, then I often move cursor from mini buffer
    to some other buffer. Normally screen is split into two or more buffer. If
    I move the ot [...] 
 
 Content analysis details:   (1.4 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [197.157.0.57 listed in zen.spamhaus.org]
 -2.3 RCVD_IN_DNSWL_MED      RBL: Sender listed at https://www.dnswl.org/,
                             medium trust
                             [209.51.188.17 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H4      RBL: Very Good reputation (+4)
                             [209.51.188.17 listed in wl.mailspike.net]
  0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=admin%40protected.rcdrun.com;ip=209.51.188.17;r=debbugs.gnu.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders


Description of the bug:

When I have action to repeatedly be asked something from mini buffer,
then I often move cursor from mini buffer to some other buffer. Normally
screen is split into two or more buffer. If I move the other window's
buffer to something else like picture by using (next-buffer) bound on
the key, I am then reading the picture and getting information which I
then enter into mini buffer. When I press enter in the minibuffer the
other window's buffer where the picture was switches back to what it was
previously. In my opinion it should not as user has decided to switch
buffer of that window to something else.

To repeat:

- bind command next-buffer to F5

- you may split window, but need not. Just have more than 1 buffer in total

- run this function

(defun ask-repeat ()
  (unless (string=3D (read-from-minibuffer "What? ") "bye")
    (ask-repeat)))

(ask-repeat)

- from mini buffer move cursor to the window

- press F5 to switch to next buffer

- move cursor back to mini buffer and enter something

At that point one may see that the window's buffer switched back to
what it was previously. User's workflow is disturbed.


In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo versio=
n 1.14.8, Xaw3d scroll bars)
 of 2020-11-25 built on protected.rcdrun.com
Repository revision: 30c437752df0a3a9410f1249fa0f237110811af2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre

Configured using:
 'configure --prefix=3D/package/text/emacs --with-modules
 --with-x-toolkit=3Dlucid'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=3Dexwm-xim
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  text-scale-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny rfc822 mml
mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map text-property-search seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils macros kmacro time-date subr-x help-fns
radix-tree cl-print debug backtrace help-mode easymenu find-func
dired-aux cl-loaddefs cl-lib dired dired-loaddefs face-remap tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 61185 11565)
 (symbols 48 7938 1)
 (strings 32 22818 2137)
 (string-bytes 1 719909)
 (vectors 16 12953)
 (vector-slots 8 179043 11957)
 (floats 8 33 37)
 (intervals 56 359 8)
 (buffers 984 15))

--=20
Thanks,
Jean Louis
=E2=8E=94 =CE=BB =F0=9F=84=AF =F0=9D=8D=84 =F0=9D=8C=A1 =F0=9D=8C=9A




Acknowledgement sent to Jean Louis <bugs@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#45072; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 15 Dec 2020 08:00:02 UTC

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