From unknown Sun Aug 17 04:16:09 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#45072 <45072@debbugs.gnu.org> To: bug#45072 <45072@debbugs.gnu.org> Subject: Status: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing Reply-To: bug#45072 <45072@debbugs.gnu.org> Date: Sun, 17 Aug 2025 11:16:09 +0000 retitle 45072 28.0.50; Emacs switches other buffer back uncontrollably, if = other window's buffer is changed by user during minibuffer editing reassign 45072 emacs submitter 45072 Jean Louis severity 45072 minor tag 45072 fixed thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 06 09:08:47 2020 Received: (at submit) by debbugs.gnu.org; 6 Dec 2020 14:08:47 +0000 Received: from localhost ([127.0.0.1]:49226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kluiU-0004LP-Pc for submit@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 ) id 1kluiT-0004LG-8i for submit@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 ) id 1kluiT-0001Dw-1c for bug-gnu-emacs@gnu.org; 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 ) id 1kluiQ-0007EI-W4 for bug-gnu-emacs@gnu.org; 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 To: bug-gnu-emacs@gnu.org 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@gnu.org::z56ZZ1G29TzEWvY1:00000000000000000000000000000000000000001pE4 Date: Sun, 06 Dec 2020 17:07:14 +0300 Message-ID: <86eek3hvu5.fsf@protected.rcdrun.com> 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@protected.rcdrun.com; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 11:10:53 2020 Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 16:10:53 +0000 Received: from localhost ([127.0.0.1]:55094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmJ6D-0000re-5p for submit@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 ) id 1kmJ6B-0000rN-9J for 45072@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 ) id 1kmJ61-0007Qp-Cd; Mon, 07 Dec 2020 17:10:44 +0100 From: Lars Ingebrigtsen To: Jean Louis 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@protected.rcdrun.com> 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@protected.rcdrun.com> (Jean Louis's message of "Sun, 06 Dec 2020 17:07:14 +0300") Message-ID: <87eek1fvgf.fsf@gnus.org> 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 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jean Louis 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 11:43:14 2020 Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 16:43:14 +0000 Received: from localhost ([127.0.0.1]:55259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmJbW-00060y-6z for submit@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 ) id 1kmJbU-00060l-Gi for 45072@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 To: Lars Ingebrigtsen 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87eek1fvgf.fsf@gnus.org> 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 [2020-12-07 19:11]: > Jean Louis 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 [2020-12-07 19:11]: > Jean Louis 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 [2020-12-07 19:11]: > Jean Louis 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? From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 12:20:29 2020 Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 17:20:29 +0000 Received: from localhost ([127.0.0.1]:55370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmKBZ-0004uC-J5 for submit@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 ) id 1kmKBW-0004tw-4C for 45072@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Jean Louis In-Reply-To: (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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: larsi@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 7 Dec 2020 19:42:45 +0300 > From: Jean Louis > Cc: 45072@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). From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 13:53:25 2020 Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 18:53:25 +0000 Received: from localhost ([127.0.0.1]:55494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmLdS-00056K-Sg for submit@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 ) id 1kmLdG-00055y-Jq for 45072@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 To: Eli Zaretskii 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <83eek18ref.fsf@gnu.org> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: larsi@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 [2020-12-07 20:20]: > > Date: Mon, 7 Dec 2020 19:42:45 +0300 > > From: Jean Louis > > Cc: 45072@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 [2020-12-07 20:20]: > > Date: Mon, 7 Dec 2020 19:42:45 +0300 > > From: Jean Louis > > Cc: 45072@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? From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 14:28:20 2020 Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 19:28:20 +0000 Received: from localhost ([127.0.0.1]:55515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmMBH-0005vj-W8 for submit@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 ) id 1kmMBD-0005vS-NQ for 45072@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Jean Louis In-Reply-To: (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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: larsi@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 7 Dec 2020 21:49:02 +0300 > From: Jean Louis > Cc: larsi@gnus.org, 45072@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. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 14:48:13 2020 Received: (at 45072) by debbugs.gnu.org; 7 Dec 2020 19:48:13 +0000 Received: from localhost ([127.0.0.1]:55550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmMUX-0006RC-EG for submit@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 ) id 1kmMUU-0006Qv-Cq for 45072@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 To: Eli Zaretskii 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <835z5d8lhc.fsf@gnu.org> 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 [2020-12-07 22:28]: > > Date: Mon, 7 Dec 2020 21:49:02 +0300 > > From: Jean Louis > > Cc: larsi@gnus.org, 45072@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@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 [2020-12-07 22:28]: > > Date: Mon, 7 Dec 2020 21:49:02 +0300 > > From: Jean Louis > > Cc: larsi@gnus.org, 45072@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 [2020-12-07 22:28]: > > Date: Mon, 7 Dec 2020 21:49:02 +0300 > > From: Jean Louis > > Cc: larsi@gnus.org, 45072@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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 00:33:16 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 05:33:16 +0000 Received: from localhost ([127.0.0.1]:56299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmVch-0008Ca-W9 for submit@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 ) id 1kmVcg-0008CO-9j for 45072@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 ) 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 ) id 1kmVcX-0005IE-PM; Tue, 08 Dec 2020 00:33:06 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <83eek18ref.fsf@gnu.org> (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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> Message-Id: Date: Tue, 08 Dec 2020 00:33:05 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: larsi@gnus.org, bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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) From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 03:10:09 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 08:10:09 +0000 Received: from localhost ([127.0.0.1]:56463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmY4W-0003rB-Gg for submit@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 ) id 1kmY4T-0003qQ-Vo for 45072@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 , Jean Louis References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> From: martin rudalics Message-ID: Date: Tue, 8 Dec 2020 09:09:28 +0100 MIME-Version: 1.0 In-Reply-To: <835z5d8lhc.fsf@gnu.org> 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@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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-- From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 09:09:30 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 14:09:30 +0000 Received: from localhost ([127.0.0.1]:56993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmdgH-0008Kg-QE for submit@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 ) id 1kmdgG-0008KU-7K for 45072@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 ) id 1kmdg4-0002mE-BZ; Tue, 08 Dec 2020 15:09:21 +0100 From: Lars Ingebrigtsen To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> X-Now-Playing: Act 4's _Circuit City_: "No More Wires" Date: Tue, 08 Dec 2020 15:09:15 +0100 In-Reply-To: (martin rudalics's message of "Tue, 8 Dec 2020 09:09:28 +0100") Message-ID: <87lfe8jsok.fsf@gnus.org> 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 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 , Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) martin rudalics 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 09:47:50 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 14:47:50 +0000 Received: from localhost ([127.0.0.1]:57076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmeHO-00056t-LI for submit@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 ) id 1kmeHM-00056g-UL for 45072@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 References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> From: martin rudalics Message-ID: <9286deee-b549-0441-9571-e7d712c5fdd5@gmx.at> Date: Tue, 8 Dec 2020 15:47:10 +0100 MIME-Version: 1.0 In-Reply-To: <87lfe8jsok.fsf@gnus.org> 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 , Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 10:04:54 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:04:54 +0000 Received: from localhost ([127.0.0.1]:59132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmeXt-0008Br-LS for submit@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 ) id 1kmeXr-0008BV-1X for 45072@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 To: Lars Ingebrigtsen 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87lfe8jsok.fsf@gnus.org> 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 [2020-12-08 17:10]: > martin rudalics 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 , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 [2020-12-08 17:10]: > martin rudalics 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 [2020-12-08 17:10]: > martin rudalics writes: Thank you all! Jean From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 10:04:59 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:04:59 +0000 Received: from localhost ([127.0.0.1]:59142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmeXz-0008CY-9j for submit@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 ) id 1kmeXt-0008BW-JJ for 45072@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 To: martin rudalics 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <9286deee-b549-0441-9571-e7d712c5fdd5@gmx.at> 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@gmx.at> 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 [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 , Eli Zaretskii , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 [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 [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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 10:13:48 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:13:48 +0000 Received: from localhost ([127.0.0.1]:59174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmegW-0008Rj-6R for submit@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 ) id 1kmegV-0008RX-4g for 45072@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: rms@gnu.org In-Reply-To: (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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> 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@gnus.org, bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Richard Stallman > Cc: bugs@gnu.support, larsi@gnus.org, 45072@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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 10:51:53 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 15:51:53 +0000 Received: from localhost ([127.0.0.1]:59275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmfHN-0005FS-0U for submit@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 ) id 1kmfHK-0005FF-Ph for 45072@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87lfe8jsok.fsf@gnus.org> (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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: rudalics@gmx.at, bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , Jean Louis , > 45072@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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 11:08:58 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 16:08:58 +0000 Received: from localhost ([127.0.0.1]:59308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmfXu-0007nq-Dk for submit@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 ) id 1kmfXr-0007nb-Ar for 45072@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Jean Louis In-Reply-To: (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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <9286deee-b549-0441-9571-e7d712c5fdd5@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: rudalics@gmx.at, larsi@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 8 Dec 2020 17:58:40 +0300 > From: Jean Louis > Cc: Lars Ingebrigtsen , Eli Zaretskii , > 45072@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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 11:14:44 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 16:14:44 +0000 Received: from localhost ([127.0.0.1]:59316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmfdU-0007wr-BR for submit@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 ) id 1kmfdS-0007wd-Bc for 45072@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 To: Eli Zaretskii 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: References: <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <9286deee-b549-0441-9571-e7d712c5fdd5@gmx.at> <83eek0701j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <83eek0701j.fsf@gnu.org> 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 [2020-12-08 19:09]: > > Date: Tue, 8 Dec 2020 17:58:40 +0300 > > From: Jean Louis > > Cc: Lars Ingebrigtsen , Eli Zaretskii List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 [2020-12-08 19:09]: > > Date: Tue, 8 Dec 2020 17:58:40 +0300 > > From: Jean Louis > > Cc: Lars Ingebrigtsen , Eli Zaretskii [2020-12-08 19:09]: > > Date: Tue, 8 Dec 2020 17:58:40 +0300 > > From: Jean Louis > > Cc: Lars Ingebrigtsen , Eli Zaretskii , > > 45072@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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 14:21:01 2020 Received: (at 45072) by debbugs.gnu.org; 8 Dec 2020 19:21:02 +0000 Received: from localhost ([127.0.0.1]:59822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmiXl-0004bW-Hd for submit@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 ) id 1kmiXj-0004bA-AM for 45072@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@linkov.net) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id A03C1240005; Tue, 8 Dec 2020 19:20:51 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> Date: Tue, 08 Dec 2020 21:15:06 +0200 In-Reply-To: (martin rudalics's message of "Tue, 8 Dec 2020 09:09:28 +0100") Message-ID: <87pn3k87tx.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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*. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 04:34:09 2020 Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 09:34:09 +0000 Received: from localhost ([127.0.0.1]:32792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmvrM-00039J-SB for submit@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 ) id 1kmvrK-00038m-HW for 45072@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 , Lars Ingebrigtsen References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> From: martin rudalics Message-ID: <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> Date: Wed, 9 Dec 2020 10:33:26 +0100 MIME-Version: 1.0 In-Reply-To: <83h7ow70ty.fsf@gnu.org> 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@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 04:34:44 2020 Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 09:34:44 +0000 Received: from localhost ([127.0.0.1]:32803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmvrw-0003Aa-GI for submit@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 ) id 1kmvrr-00039x-T9 for 45072@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 References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> From: martin rudalics Message-ID: Date: Wed, 9 Dec 2020 10:34:01 +0100 MIME-Version: 1.0 In-Reply-To: <87pn3k87tx.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 09:03:04 2020 Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 14:03:05 +0000 Received: from localhost ([127.0.0.1]:33113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn03c-0003bM-Mk for submit@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 ) id 1kn03b-0003as-76 for 45072@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 To: martin rudalics 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: 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 [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 , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.1 (/) * martin rudalics [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. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 10:17:20 2020 Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 15:17:20 +0000 Received: from localhost ([127.0.0.1]:35717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn1DT-00089f-Pf for submit@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 ) id 1kn1DS-00084D-8y for 45072@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 References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> From: martin rudalics Message-ID: <532737ad-8326-8f07-766f-780838a4718e@gmx.at> Date: Wed, 9 Dec 2020 16:16:39 +0100 MIME-Version: 1.0 In-Reply-To: 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 , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 14:22:15 2020 Received: (at 45072) by debbugs.gnu.org; 9 Dec 2020 19:22:15 +0000 Received: from localhost ([127.0.0.1]:36136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn52V-0004DE-6q for submit@debbugs.gnu.org; Wed, 09 Dec 2020 14:22:15 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:58381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn52U-0004Ck-DF for 45072@debbugs.gnu.org; Wed, 09 Dec 2020 14:22:14 -0500 Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98]) (Authenticated sender: juri@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 57BB3100005; Wed, 9 Dec 2020 19:22:05 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> Date: Wed, 09 Dec 2020 21:11:39 +0200 In-Reply-To: (martin rudalics's message of "Wed, 9 Dec 2020 10:34:01 +0100") Message-ID: <877dpqzx3o.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 02:45:39 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 07:45:39 +0000 Received: from localhost ([127.0.0.1]:36844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knGdv-0001Y0-0u for submit@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 ) id 1knGdt-0001Xl-MH for 45072@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 References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> From: martin rudalics Message-ID: <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> Date: Thu, 10 Dec 2020 08:44:57 +0100 MIME-Version: 1.0 In-Reply-To: <877dpqzx3o.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 03:32:58 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 08:32:58 +0000 Received: from localhost ([127.0.0.1]:36952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knHNi-0002nu-Fg for submit@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 ) id 1knHNh-0002n5-4I for 45072@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 To: martin rudalics 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: References: <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * martin rudalics [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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 03:34:31 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 08:34:31 +0000 Received: from localhost ([127.0.0.1]:36963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knHPD-0002qu-B7 for submit@debbugs.gnu.org; Thu, 10 Dec 2020 03:34:31 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:50031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knHPB-0002qa-Vj for 45072@debbugs.gnu.org; Thu, 10 Dec 2020 03:34:30 -0500 Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98]) (Authenticated sender: juri@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id E0EA2100009; Thu, 10 Dec 2020 08:34:21 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> Date: Thu, 10 Dec 2020 10:32:54 +0200 In-Reply-To: <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> (martin rudalics's message of "Thu, 10 Dec 2020 08:44:57 +0100") Message-ID: <87wnxqxdx5.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 04:47:14 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 09:47:14 +0000 Received: from localhost ([127.0.0.1]:37050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knIXZ-0004ew-Uy for submit@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 ) id 1knIXW-0004eh-Vz for 45072@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 References: <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> From: martin rudalics Message-ID: <8f775254-65d2-6f3d-4c71-b6f10bb2b278@gmx.at> Date: Thu, 10 Dec 2020 10:46:28 +0100 MIME-Version: 1.0 In-Reply-To: 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 , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 04:48:02 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 09:48:02 +0000 Received: from localhost ([127.0.0.1]:37054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knIYM-0004gK-7B for submit@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 ) id 1knIYK-0004fl-0u for 45072@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 References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> From: martin rudalics Message-ID: <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> Date: Thu, 10 Dec 2020 10:47:21 +0100 MIME-Version: 1.0 In-Reply-To: <87wnxqxdx5.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 05:43:49 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 10:43:49 +0000 Received: from localhost ([127.0.0.1]:37113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knJQK-000648-Q3 for submit@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 ) id 1knJQF-00063V-Np for 45072@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 To: martin rudalics 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: References: <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> 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@gmx.at> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * martin rudalics [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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 05:43:49 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 10:43:49 +0000 Received: from localhost ([127.0.0.1]:37115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knJQL-00064B-2L for submit@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 ) id 1knJQH-00063Z-5w for 45072@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 To: martin rudalics 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: References: <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <8f775254-65d2-6f3d-4c71-b6f10bb2b278@gmx.at> 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@gmx.at> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * martin rudalics [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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 06:53:07 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 11:53:07 +0000 Received: from localhost ([127.0.0.1]:37145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knKVP-0007uJ-1e for submit@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 ) id 1knKVN-0007tp-F6 for 45072@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 References: <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <8f775254-65d2-6f3d-4c71-b6f10bb2b278@gmx.at> From: martin rudalics Message-ID: Date: Thu, 10 Dec 2020 12:52:26 +0100 MIME-Version: 1.0 In-Reply-To: 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 , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 06:53:15 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 11:53:15 +0000 Received: from localhost ([127.0.0.1]:37148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knKVX-0007uf-9x for submit@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 ) id 1knKVV-0007uR-HX for 45072@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 References: <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> From: martin rudalics Message-ID: Date: Thu, 10 Dec 2020 12:52:36 +0100 MIME-Version: 1.0 In-Reply-To: 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 , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 07:44:16 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 12:44:16 +0000 Received: from localhost ([127.0.0.1]:37186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knLIu-0002qN-Jc for submit@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 ) id 1knLIr-0002q2-C5 for 45072@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 To: martin rudalics 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: References: <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <8f775254-65d2-6f3d-4c71-b6f10bb2b278@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * martin rudalics [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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 07:44:19 2020 Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 12:44:19 +0000 Received: from localhost ([127.0.0.1]:37188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knLIw-0002qW-Rg for submit@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 ) id 1knLIt-0002q5-HE for 45072@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 To: martin rudalics 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: References: <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , 45072@debbugs.gnu.org, larsi@gnus.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * martin rudalics [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. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 05:00:00 2020 Received: (at 45072) by debbugs.gnu.org; 11 Dec 2020 10:00:00 +0000 Received: from localhost ([127.0.0.1]:40021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knfDU-0007R5-2y for submit@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 ) id 1knfDJ-0007QP-Rk for 45072@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@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id AF847240016; Fri, 11 Dec 2020 09:59:40 +0000 (UTC) From: Juri Linkov To: Jean Louis 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@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <8f775254-65d2-6f3d-4c71-b6f10bb2b278@gmx.at> Date: Fri, 11 Dec 2020 11:39:32 +0200 In-Reply-To: (Jean Louis's message of "Thu, 10 Dec 2020 15:07:42 +0300") Message-ID: <874kksoeq7.fsf@mail.linkov.net> 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 , Eli Zaretskii , larsi@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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) From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 20:50:53 2020 Received: (at 45072) by debbugs.gnu.org; 12 Dec 2020 01:50:53 +0000 Received: from localhost ([127.0.0.1]:43663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knu3h-0000c5-2h for submit@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 ) id 1knu3c-0000bn-9H for 45072@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 To: Juri Linkov 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: References: <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <8f775254-65d2-6f3d-4c71-b6f10bb2b278@gmx.at> <874kksoeq7.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <874kksoeq7.fsf@mail.linkov.net> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: martin rudalics , Eli Zaretskii , larsi@gnus.org, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Juri Linkov [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 From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 12 16:08:52 2020 Received: (at 45072) by debbugs.gnu.org; 12 Dec 2020 21:08:53 +0000 Received: from localhost ([127.0.0.1]:46921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koC8K-0004vA-Ft for submit@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 ) id 1koC8H-0004ug-2U for 45072@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@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CD85560002; Sat, 12 Dec 2020 21:08:41 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> Date: Sat, 12 Dec 2020 22:49:37 +0200 In-Reply-To: <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> (martin rudalics's message of "Thu, 10 Dec 2020 10:47:21 +0100") Message-ID: <87pn3e697i.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 13 02:27:16 2020 Received: (at 45072) by debbugs.gnu.org; 13 Dec 2020 07:27:16 +0000 Received: from localhost ([127.0.0.1]:47354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koLmm-0007nt-5f for submit@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 ) id 1koLmk-0007nU-5u for 45072@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 References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> From: martin rudalics Message-ID: <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> Date: Sun, 13 Dec 2020 08:26:34 +0100 MIME-Version: 1.0 In-Reply-To: <87pn3e697i.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 14 15:37:57 2020 Received: (at 45072) by debbugs.gnu.org; 14 Dec 2020 20:37:57 +0000 Received: from localhost ([127.0.0.1]:54658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koubV-0002tZ-Gf for submit@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 ) id 1koubU-0002tJ-Ax for 45072@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@linkov.net) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id B192D240003; Mon, 14 Dec 2020 20:37:47 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> Date: Mon, 14 Dec 2020 22:28:40 +0200 In-Reply-To: <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> (martin rudalics's message of "Sun, 13 Dec 2020 08:26:34 +0100") Message-ID: <87tuso16qn.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 15 03:00:03 2020 Received: (at 45072) by debbugs.gnu.org; 15 Dec 2020 08:00:03 +0000 Received: from localhost ([127.0.0.1]:55406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kp5Fa-0001td-SP for submit@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 ) id 1kp5FY-0001sb-4r for 45072@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 References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> From: martin rudalics Message-ID: <8f134c6c-58e4-96f9-ec43-c16f781dc64f@gmx.at> Date: Tue, 15 Dec 2020 08:59:21 +0100 MIME-Version: 1.0 In-Reply-To: <87tuso16qn.fsf@mail.linkov.net> 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 , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 15 04:17:27 2021 Received: (at 45072) by debbugs.gnu.org; 15 Jan 2021 09:17:27 +0000 Received: from localhost ([127.0.0.1]:39902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0LEV-0007tB-BU for submit@debbugs.gnu.org; Fri, 15 Jan 2021 04:17:27 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:44911) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0LET-0007sl-4M for 45072@debbugs.gnu.org; Fri, 15 Jan 2021 04:17:25 -0500 X-Originating-IP: 91.129.98.64 Received: from mail.gandi.net (m91-129-98-64.cust.tele2.ee [91.129.98.64]) (Authenticated sender: juri@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 003ACC0006; Fri, 15 Jan 2021 09:17:16 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> Date: Fri, 15 Jan 2021 10:57:40 +0200 In-Reply-To: <87tuso16qn.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 14 Dec 2020 22:28:40 +0200") Message-ID: <87pn26y3uj.fsf@mail.linkov.net> 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: larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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. It seems that problem is that read_minibuf messes up the windows so much, that at the end currently the only way to fix this mess is by restoring the previous window configuration. This means that there is a need to fix read_minibuf to restore all previous window states without using restore_window_configuration. Only then it will be possible to add a user option to disable using restore_window_configuration. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 09:52:18 2021 Received: (at 45072) by debbugs.gnu.org; 19 Apr 2021 13:52:18 +0000 Received: from localhost ([127.0.0.1]:48900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYUK2-0004H1-AF for submit@debbugs.gnu.org; Mon, 19 Apr 2021 09:52:18 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7851) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYUJy-0004Gm-3F for 45072@debbugs.gnu.org; Mon, 19 Apr 2021 09:52:17 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 928A11002F2; Mon, 19 Apr 2021 09:52:08 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0633E1000C4; Mon, 19 Apr 2021 09:52:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618840327; bh=XPislJkyTa1gOqJRQ3mXHdygTuiRYnCLaf23zU4nIm0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RYX9UMZ1HGICcFpHRsSaTXLxl1ywVkwv4trc4PGj922vK4vsyyLYQB5w2KeVj7iFC nU5n/hVoZMXcMz0sW2KwzBkNpTK/FT7QNtWz6JmRUfgZW73NFINFXHyk2bktk+ivut 2WO4t+dPnbuUM3SxOrOddKUQSDnmOSXyqKiy6kGhwanrnwQd8lWAE4vrDNC6PAD/c5 o/DBNFozeK2Fsja8UD1P3OU2wqCL09G/7CvRZYH7reZUZbmFFa00QTZ0PxatV+NKyw 36hH+CNwRoTX9BRlEgbMxQqPdPkEP1wvNUOTwGN1F/PxouprRsjegeu6dXCvodQQBV StqOhYpiupKhA== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BABB412023C; Mon, 19 Apr 2021 09:52:06 -0400 (EDT) From: Stefan Monnier To: Juri Linkov 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> Date: Mon, 19 Apr 2021 09:52:06 -0400 In-Reply-To: <87tuso16qn.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 14 Dec 2020 22:28:40 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: martin rudalics , Eli Zaretskii , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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? Part of the problem is one of documentation: it's hard to know which one to call just by reading the docstrings. Also the above quoted text sounds counter intuitive: "bury buffer" sounds like it's mostly focused on hiding the *buffer*, potentially hiding the window along the way if necessary, whereas "quit window" sounds like it's mostly going to eliminate the *window*. Of course, there's also the fact that `quit-window` is fairly new (introduced in Emacs-24), whereas `bury-buffer` has been with us forever. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 09:54:23 2021 Received: (at 45072) by debbugs.gnu.org; 19 Apr 2021 13:54:23 +0000 Received: from localhost ([127.0.0.1]:48913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYUM3-0004KJ-0D for submit@debbugs.gnu.org; Mon, 19 Apr 2021 09:54:23 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYULz-0004Jz-Lz for 45072@debbugs.gnu.org; Mon, 19 Apr 2021 09:54:20 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 56BB080A77; Mon, 19 Apr 2021 09:54:14 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 15AB8805D6; Mon, 19 Apr 2021 09:54:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618840453; bh=jiv8KkUHw3pVpghpNsSdhfKU8LlEsGdBx0kF6bZHVGI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=AfL11R65zGgdkdlVwcRop7EwY7PImkbCtu5ZZVmyo/JFnR0G4vsFQCBnSsZer7LtF TgL5xhh4BC9yN4/rS6kqCgc5P0wTgWJ0e5OHVOz5G+Qq5pTOoOup0cmt1YL90Xf0Ea SN3RMFbd2yOIKk1ufIA0MmzcVWLrqqD1jnhmd/xMBlJEFr675ZYzpVCwYDdenaXqbt lLeNbilRXU2lwbtAHtBJsy2DPlUs5p9PJCmiNZAVW+8KARNnhoji6N8KBlIBt5Crrg MIi8tsjwvljiz86JaDBFKsAUOASNYWVhA3AOBOXy3yztQCtTwsC7El6z0sbdkP50Aa /7gaMwADd5aTg== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C798612018F; Mon, 19 Apr 2021 09:54:12 -0400 (EDT) From: Stefan Monnier To: Juri Linkov 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> <87pn26y3uj.fsf@mail.linkov.net> Date: Mon, 19 Apr 2021 09:54:12 -0400 In-Reply-To: <87pn26y3uj.fsf@mail.linkov.net> (Juri Linkov's message of "Fri, 15 Jan 2021 10:57:40 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.054 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: martin rudalics , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > It seems that problem is that read_minibuf messes up the windows so much, > that at the end currently the only way to fix this mess is by restoring > the previous window configuration. This means that there is a need > to fix read_minibuf to restore all previous window states without using > restore_window_configuration. Only then it will be possible to add > a user option to disable using restore_window_configuration. But without such an option, it's hard to find and fix the problems, because they're hidden by the `restore_window_configuration`. So maybe we should introduce such an option, and then force ourselves to live with it and then fix the problems we encounter. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 12:03:03 2021 Received: (at 45072) by debbugs.gnu.org; 19 Apr 2021 16:03:03 +0000 Received: from localhost ([127.0.0.1]:51821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYWMZ-00027E-9z for submit@debbugs.gnu.org; Mon, 19 Apr 2021 12:03:03 -0400 Received: from mout.gmx.net ([212.227.15.18]:60773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYWMX-00026e-G4 for 45072@debbugs.gnu.org; Mon, 19 Apr 2021 12:03:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1618848141; bh=r+gFhTBaw3U57kk4wj44PcqAH6NyEBRAe21rSblupgI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=CCtWa+boCyAjbzWjqTXcU4QuefhGlL/lbJaI/5PTx38H0/qe7hw8GTC0aSVmMvl7g xDaP+/6+Li1I4+TGF490qhEb6pNFCdA+h7wkMkmNW9V9QCgCT6gBAYp7FsDmP+Rg5G 4PAUnyOtHNLpYjwZnJin8QnnrgzmbK4F1NifX3No= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.5.140]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpUUw-1lr3nU47FU-00pxcj; Mon, 19 Apr 2021 18:02:21 +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 To: Stefan Monnier , Juri Linkov References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> From: martin rudalics Message-ID: Date: Mon, 19 Apr 2021 18:02:19 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:YXVXTl3/E+dbSg27jMwq2FeqpQAzwflW4MaJcLIse69jmdJ0VPk OBeKLQiHHTyxB1RQpjMHPMn1m11v4fL67O+p/j0O6bhwWLSMxOBgJDz6luAFxidqLPO569F 3Yw8k0MsQ/CkB3pBjJjaS3Fzjtn46zqhs63vB2Pulv1KV+QvbXpq4useBmvaQCbsQkAx/kC JHOn3YDt6JHkiHMnRT9og== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:q3JmjQkQF7s=:CtCFhe8EamAXipOjQPDwzx 7z9D6lj0VX6y/gdslf2hNkAsJZfcFndezbSWzV0P7D9RuwAC6QWBXEPYj99EAkQ716CrzZwMh VCBhAi6YckUKoUPdKyqZe3bDgSr5FYbbXyJg1uGgtpszpFjC90q79cRTDd657CUUZG5Y0LjRu wW1DLy2gZPPwtUB6yXMzoRuGUcg6nWS1RdQvA4naMK4S+hmJCL8WLxLhXsGVcxTH+FSjpKbI7 YQsyl5kA/TBGIx6MI8topYe6LgS3+9UsdNuQtla4KUQs1albiiErx6zcbyxFsFhnBEqMWf5KN kIeb73BHG6j2NA+t+xLjE2DSUJi/PI7cn9ex839pz9BKZkrQh3BYEj/QcdIClkBHQl4m9DqbR u9/AEzKWKN0OU3rGKqm0WJcwEsJXdpxdcjw3qp8dLSpIyO2hzQr503x3nGmROZKZa78jjILoq Zq99p3Owmzf0oshT1s025uFbgzoWx6kjJt4YdWx0Ofarg/CzXa4DJhbZ4ZO9/gKPnjzk+qwER InA84I5b0nVbFaFRhudUNeQHOzhi41RUaMlC1I2CMXGwqCNXH6IOf0qpPaGbVhFAcT0IVLHiA Q0/kvmFCC+y6IzFMSm13SjfBFo61hwKM7+bbZAHilEUB21FkUwY1G0yrQbqZm8FTcS+6tcSuO NKisZLh4FkM5RCYa8wXGpDKwl/4aR00u+J4e1zi7wTMI4kSMGJHDofUnUTswume2qR7Z52ljS RIJPbrglD+MQJg0GymedA8rdjTXzALRBH5S9MNek096xRzJMZph05OwmpIYKRLT7mERmlppDm 7V3H6reZ2pj/cwNe/N9W6bCJukZBzq+pbKZ1u2r0tWk921Ch/sfmgZrK+ctbcxh6M+JsgPoaa QVvlmeEf60dRzOUzPufx3VnGPxRzkMW0JLIiKMQMXTdvIBD9l/7RaQis5oKRq8OmX4keiMYQN zOp7S9KY69Wm1Yx3t+15vY4YyO2DBIvILNuWnYqusM2vKVDpYbY+gE7CUfXGH+r08BegUUhuN MmavNcoFOPDwc1idSqYPRmSYZFsz++6kmjpQ6OgPnB3xM3+4hRomILLIw+Gw8+RcvO4ELqBjy qBIaF/nVsOH+GebY3qP7nM2fYxKSk2KN0CM63vZbhwvje2GQr3fer9xB1rjkTpF5YTVtH2DBZ 6CbBHyJRKbuUitODBm4jCscY5FMR2awxAe6NEFT5qnFecQGKt/lvMfhsQWseNPd1U1wMw= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>> 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? > > Part of the problem is one of documentation: it's hard to know which one > to call just by reading the docstrings. > > Also the above quoted text sounds counter intuitive: "bury buffer" > sounds like it's mostly focused on hiding the *buffer*, potentially > hiding the window along the way if necessary, whereas "quit window" > sounds like it's mostly going to eliminate the *window*. That's why Lisp code should call `quit-restore-window' instead of `quit-window'. > Of course, there's also the fact that `quit-window` is fairly new > (introduced in Emacs-24), whereas `bury-buffer` has been with us forever. Both, `bury-buffer' and `quit-window' should be used interactively only. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 12:03:21 2021 Received: (at 45072) by debbugs.gnu.org; 19 Apr 2021 16:03:21 +0000 Received: from localhost ([127.0.0.1]:51824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYWMl-00027m-H3 for submit@debbugs.gnu.org; Mon, 19 Apr 2021 12:03:21 -0400 Received: from mout.gmx.net ([212.227.15.15]:40985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYWMk-00027X-Bx for 45072@debbugs.gnu.org; Mon, 19 Apr 2021 12:03:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1618848156; bh=fLKwLnDuh5g2QSH70E8TSkg0cx4rJgq8QxpTo1rohGw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=gzhFcGq4A/EhtUWvq187Rye81HiBXub7csgVJI++ARwIrGS8Q1XXSvTNvoGY/CmOe h60fomaPdq83vdp22Y+peTaQ14S+ra7NNcZ5F2S+tIfhMt1xWuRCcMPJTTqW1E0Tt9 WxRZSmsctVkeYpUZCzF7cQE7tFTyBfqAdIfbfNVk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.5.140]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCsPy-1lPgfT3bRQ-008umG; Mon, 19 Apr 2021 18:02:35 +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 To: Stefan Monnier , Juri Linkov References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> <87pn26y3uj.fsf@mail.linkov.net> From: martin rudalics Message-ID: <85dc6e0f-4430-0c82-4b96-aa7e2b92d937@gmx.at> Date: Mon, 19 Apr 2021 18:02:35 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:feP/JmEVdCs2UjNWEo5oSllWojb/OmMXJoPuqjtR1LCMB+dj1hL PEKCG4q5YAkB4IR4dCzzZoqIlgjKTAQu/qYuwNis+5g+h/J3MTB4E3bGYpit7ZOjNrDKE69 XS+R/Scn8feweZ+JOCU9s2rNfA61Tv9YWRzmvtrNGsB1zB150uCJJi0JMYqERyhV59j1P2X 7KNBO+lK7SZD8++14m+SA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:CVjComS2zV8=:aVN0CjJfWd1s6SV9o+J6M+ Vxoxgx5jWwEEoTYGP03SMPyasCZFR2skbPX6Jm+CyLlBfAKA63HWtwuBKVNAf8pOj0YbyEPo2 yD4wS+dWfhWmtgOQB/1zVk04ORwgXKwLGMWo45SkdKvn3pSh6oolFUOLBHlOmfrTDZ/4784OG m0lyp+7NuJC74UdV5QSWOSKVnXhxxn8gb3PeCAL/6ler9xq7lIMpW83hpmuN65AQO84uKZUiK vjr+Va15l6AYFGtHolDV3Hwy07GS/HzyZTxPwsfdGZc5BPA9k53T8olC1k1Ts7tXEu7OOAdRS J11KQS72tlmWsraBIM1VJPRDXzFXth45I/wEpmOep4yjcMoO37l7OGQixUX7QEXDQC5FBeErH aqfIhg36ml6Mkl3EXZz25U0ff25xfvj3fMReo8fIEe79yb6pRZq878GfNaMRYEsGzRlma04Hs /TaxisdF2B5YeBBtzNm4Jvlft/855/wG5vbheN2vBnlEjmKpkQ8LY31fB00w3U25AixZ1OaoJ ezpH7fujBecsOSHqk2uG6tVELE4Si+LJaJKg+NEUtEKoY8PwWaJs3pVfaE2v25S70YhIscxBi pH8KuT6ZNkH92H+heFeMv8Z43WIO1kHsJdAWV4tKchRsn5g+DpH4eLAknwg6ICk5oVHukDu1o 4gkk9vp6Ghfzk1FU8BkzZLF+u41aKvumN/HxmR9HkIB58dDUnP9Geg9mbd1Pq/F9lpsb5nqe2 pz+GBozN/vo/mB/kzq+pv1zd4JXJfreHdA0buVwMARHDPh4yiSsTiQOkXcuPhJCOKudPwCBfU lIxM566isWoshMceXdovEMz2yJmuRkx1+vGimrH/j/K25VnitQ8EWXot13p461IOoBBfId97g f5bpijykHYd45Yrf74yPUUiSZwkyB+8X2E+HEbxRev/xUuFhv4S7tH9yhSUL7HM4lGivHPvuW gnCs/rsNDU9OOY6CbJBLNBKuxcr0rH1Zyuod7NEJ71bYlJWd/2B1Jd+yIl2Lk43ZbXF+7MDfF gSPY3+XEgOulsH2WZSfhhYwgqQ95z585IgoH3CTMhSvjsZMKS0aem13esO3V7aoMwyeG+3TTO GrTb7Jc2mQ49jiXlf96N3p++k/kf/wfeeF2YIrrfpGPmAOJTYWLkltPVCcvKzwxO8l5d8XUVA YbQIMnUMJDarr+KXGszvjJs+urGpghAQXCFmzNhnp50YPjE9PJobp7repOUerQ5OtDORE= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: larsi@gnus.org, Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> It seems that problem is that read_minibuf messes up the windows so much, >> that at the end currently the only way to fix this mess is by restoring >> the previous window configuration. This means that there is a need >> to fix read_minibuf to restore all previous window states without using >> restore_window_configuration. Only then it will be possible to add >> a user option to disable using restore_window_configuration. > > But without such an option, it's hard to find and fix the problems, > because they're hidden by the `restore_window_configuration`. > So maybe we should introduce such an option, and then force ourselves to > live with it and then fix the problems we encounter. Exiting from and quitting `read-minibuffer' is hairy, in particular with multiple frames. IIRC it's hard to tell for an application how to clean up the state when the user quits and throws it back to the top level. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 12:22:28 2021 Received: (at 45072) by debbugs.gnu.org; 19 Apr 2021 16:22:28 +0000 Received: from localhost ([127.0.0.1]:51854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYWfI-0002bo-BZ for submit@debbugs.gnu.org; Mon, 19 Apr 2021 12:22:28 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYWfD-0002bW-FP for 45072@debbugs.gnu.org; Mon, 19 Apr 2021 12:22:23 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E5A8644118D; Mon, 19 Apr 2021 12:22:13 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9F432440FB3; Mon, 19 Apr 2021 12:22:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618849332; bh=W0FBUlUSQCokbqiaqJ+Htlx92ulMHZ1rpH+hggUnrr8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nfqafwTo6MSYxhKTVQ03auwqJAz0iR5AJP6XWkTzoga+n4jDkdFzbiKXe3cqmpJhw lyTf2AfxKt93o+MaKcFZIYMgkogIsPhx31fBv2EmPicUJd+nb1oASiOmIevCrv0yro MGtjqOUtVsfYNbtn4nslDn/YF069uUb28tHCu5yq5PAjSx/6nTanpAqGzrzzy17BqW vZhsm8E+LitU1VBciQL2zJc2P8M/dZRlzPf2VgWATEzVmRi30/pOusXf6vwyAZjQjJ tdQLTewZHoIureiIdjqJ5tO45pZZj6Ac6e8aGfhq/NVZFRhA2xRXNySTzYLcCH3AF6 iA31C5XAsOmZA== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0C1631202A0; Mon, 19 Apr 2021 12:22:12 -0400 (EDT) From: Stefan Monnier To: martin rudalics 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: References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> Date: Mon, 19 Apr 2021 12:22:11 -0400 In-Reply-To: (martin rudalics's message of "Mon, 19 Apr 2021 18:02:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.099 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , 45072@debbugs.gnu.org, larsi@gnus.org, Jean Louis , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> Maybe 'quit-window' is better? >> >> Part of the problem is one of documentation: it's hard to know which one >> to call just by reading the docstrings. >> >> Also the above quoted text sounds counter intuitive: "bury buffer" >> sounds like it's mostly focused on hiding the *buffer*, potentially >> hiding the window along the way if necessary, whereas "quit window" >> sounds like it's mostly going to eliminate the *window*. > > That's why Lisp code should call `quit-restore-window' instead of > `quit-window'. I suspect the docstring of the other functions should point to it if we want this to have any uptake. >> Of course, there's also the fact that `quit-window` is fairly new >> (introduced in Emacs-24), whereas `bury-buffer` has been with us forever. > Both, `bury-buffer' and `quit-window' should be used interactively only. Maybe we should begin with adding (declare (interactive-only quit-restore-window)) to `quit-window` (adding it to `bury-buffer` risks us drowning under a deluge of warnings)? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 13:12:35 2021 Received: (at 45072) by debbugs.gnu.org; 19 Apr 2021 17:12:35 +0000 Received: from localhost ([127.0.0.1]:51906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYXRq-0005yg-Q9 for submit@debbugs.gnu.org; Mon, 19 Apr 2021 13:12:34 -0400 Received: from mout.gmx.net ([212.227.15.15]:37989) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYXRo-0005yQ-Kl for 45072@debbugs.gnu.org; Mon, 19 Apr 2021 13:12:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1618852312; bh=dWKoC/I0U3AJBe5npoSZVQlAJNPK9eVWH4CssXMXVtI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=SDAukeFIHQ9Q0/b82UVw9ZGYP/4tilkIaYL5feHXt7lt9nRyH83NaOyDgSjqCi8VZ +QBNxRdC5f+qV8SdterL1z+PIwNnXRPY/T9cHxZwyAphpy3VBFyzK2O4WwSycEqcFk SSw1qtkDjNKQJMmI93CdXSVQAchySALLuKxwGd8c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.5.140]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N3bWr-1lhVgK3IB9-010bSe; Mon, 19 Apr 2021 19:11:51 +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 To: Stefan Monnier References: <86eek3hvu5.fsf@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> From: martin rudalics Message-ID: <3434dc6c-d70a-a0d0-ce19-7d8694f6b52f@gmx.at> Date: Mon, 19 Apr 2021 19:11:49 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:n/H0eGAA4NgmTqhdNdGEEH3t7RrQ/7Jpal3TS/AtsqDYkWsgXB0 tEKE+xo0lIf8jCczAFoIu3rbJ2JU2gZ0qjIVu0v8qcphXw0zR8NAABeJvbVZ2PqZofQ7N3m D71aXIAPSZjsInAif7mKPFxyHO8+ncXxpmiFUyrZ6HnYIol/y5QWCdZuO5dtshEwhrUr+Qz T4lZ5fBmjuv6bD6XBnWVw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:RSPCcM7QkDA=:MvfrIu81UGOOZgWY2jc7vo lEN7RJt4EbHo1qk1fRzPNPz5Q3y6KQwB1dhMS60bOJB8Hhtr1egwl9oC1D0KQyVdJQipYL67r BDJvb5Cg6LmYRu9Hg9/vLYDlr9DoNHzWEFGh58MryFDCN3HXrTGrxipQ9HhjPUhXkuVC2R01x Hm4kBQkyYQe6d2xqk+6+MwOU6nf4CdzJ48d7NXuQ6Rctx/GKvWiMyhvMIZpNepvREnZRRMoaj OZhOBOC7dpFTLTEFsln2Kaqd3/00PCYZ+LOlWHHeLBLPjQlykpXTXcKitbEkaA9+nrW/sGSFy c/26ufqOL4kXDWMwweKAqbuI/2JaRgzrS/4RmYB19vOZuIy1v2Q0o1kHHeKeQg5iZSRPrjYCo QxmiyH58yonszi7i3Kds/KjjmNV3MgrdVAVdSC9U2chcXvwi4qe1USTjLecxlTCBFtznSE4s9 vX+pXW0LMzymyYunfUFahXsjlFEnxB9P+3RXOLpYwQN/Q/LS1cISzq+6oSw6rXstSK7Jn7gHA VxNSRYmf3ihAXB8z0CwEb+D+GJQ+AQ8rCz2td7PabS56FJJfpz54XFajqoZFzY2ZAk19HZX6m Ndq7HawfuOlfJAPQBb6Bh8BxCeTPgEQ6QZ3CoFgsyN3ssV6DtAgsT6+zCCi1eKqDGeew5HUhj 9W6k9FU2dSs9Tg2AnKHjyvEUGroJwf6bHLuj/TqBMGVsKpiG75591AlxmlfvYD8HzKkO8o+oP UHb85zyOtHqRZVteUQ8gGEEuzr+UHiLdFerZsbqU0xM7d5ClQU7G5qCGXbIQFc8xwsPK0aq92 p/AEzpijLLNUFqh5aENTS1Zeoi2MgJ3v4MrRY8f+X/ipawBSt3h5zii/dOU5pRudCaDB1LADg ui6xHmuK6XYXgQEAYOq/wJDeJ5pdi7FvZfIDcsrDfez8wYj31r9em3PHn0VKJM6X4/4v3NdGQ g/kPBrgC0NM2csr8M9S9ruZqLbqi/UXGPjHAa01UFe7KAIDIr9siXAPhcGozGFLR3mf/ot0P1 0FG7P+l//SiwFSRHrdaie8B+/GdluHlZyIx8PsnlasxWR5L4dHASgs4qAkygGm9Z0zSDvjacy DeIhqXdY1BpMpXbsC4/f+AuBqls2NKeV25dipyTVlY9OKi64ap6/SDcQbqE8CLZxHp1jpJRg0 senFDH0ub348AY9bK3CZa3NpoxcMj5TWbzWtMInEDngTiEeQ24RBF9osk+CcAAmjIUFmU= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , 45072@debbugs.gnu.org, larsi@gnus.org, Jean Louis , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> That's why Lisp code should call `quit-restore-window' instead of >> `quit-window'. > > I suspect the docstring of the other functions should point to it if we > want this to have any uptake. I would have given up on that idea at the latest when `quit-window-hook' was added. > Maybe we should begin with adding > > (declare (interactive-only quit-restore-window)) > > to `quit-window` (adding it to `bury-buffer` risks us drowning under > a deluge of warnings)? At the time people call `quit-window' and/or `bury-buffer' they are only occupied with how to get rid of one of these ASAP. When they find out that they overdid things, they usually try to restore some older window configuration. These habits will never die. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 14:22:30 2021 Received: (at 45072) by debbugs.gnu.org; 19 Apr 2021 18:22:30 +0000 Received: from localhost ([127.0.0.1]:52034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYXW-0007x6-Dm for submit@debbugs.gnu.org; Mon, 19 Apr 2021 14:22:30 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:50705) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYXT-0007wq-GN for 45072@debbugs.gnu.org; Mon, 19 Apr 2021 14:22:28 -0400 Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166]) (Authenticated sender: juri@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 0093F240008; Mon, 19 Apr 2021 18:22:18 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <87wnxqxdx5.fsf@mail.linkov.net> <73e2a032-d3e9-bc94-2f72-246096ce03cb@gmx.at> <87pn3e697i.fsf@mail.linkov.net> <35666a8a-6888-972c-4e20-bf05cf09d764@gmx.at> <87tuso16qn.fsf@mail.linkov.net> <87pn26y3uj.fsf@mail.linkov.net> <85dc6e0f-4430-0c82-4b96-aa7e2b92d937@gmx.at> Date: Mon, 19 Apr 2021 21:09:59 +0300 In-Reply-To: <85dc6e0f-4430-0c82-4b96-aa7e2b92d937@gmx.at> (martin rudalics's message of "Mon, 19 Apr 2021 18:02:35 +0200") Message-ID: <87eef6nqdc.fsf@mail.linkov.net> 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: larsi@gnus.org, Stefan Monnier , Jean Louis , 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>> It seems that problem is that read_minibuf messes up the windows so much, >>> that at the end currently the only way to fix this mess is by restoring >>> the previous window configuration. This means that there is a need >>> to fix read_minibuf to restore all previous window states without using >>> restore_window_configuration. Only then it will be possible to add >>> a user option to disable using restore_window_configuration. >> >> But without such an option, it's hard to find and fix the problems, >> because they're hidden by the `restore_window_configuration`. >> So maybe we should introduce such an option, and then force ourselves to >> live with it and then fix the problems we encounter. > > Exiting from and quitting `read-minibuffer' is hairy, in particular with > multiple frames. IIRC it's hard to tell for an application how to clean > up the state when the user quits and throws it back to the top level. Since restore_window_configuration doesn't restore multiple frames, we already don't clean up the previous state completely. So maybe really it should be sufficient for a new option just to select the original window if it still exists. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 03 04:15:46 2021 Received: (at 45072) by debbugs.gnu.org; 3 Aug 2021 08:15:46 +0000 Received: from localhost ([127.0.0.1]:39806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mApaU-0007zF-Eh for submit@debbugs.gnu.org; Tue, 03 Aug 2021 04:15:46 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:48479) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mApaS-0007yn-HE for 45072@debbugs.gnu.org; Tue, 03 Aug 2021 04:15:44 -0400 Received: (Authenticated sender: juri@linkov.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 5746B1C0007; Tue, 3 Aug 2021 08:15:35 +0000 (UTC) From: Juri Linkov To: martin rudalics 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> Date: Tue, 03 Aug 2021 10:57:04 +0300 In-Reply-To: <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> (martin rudalics's message of "Wed, 9 Dec 2020 10:33:26 +0100") Message-ID: <87fsvr55n7.fsf@linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45072 Cc: Eli Zaretskii , Lars Ingebrigtsen , bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain >> Yes. But maybe read-from-minibuffer-restore-windows would be even >> better. > > And `read-minibuffer-restore-windows' would be even shorter. Attached. > > + 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 = true; I recommend to install this patch. Maybe it's not perfect, but works reasonably well, and there is the high demand for this feature. Only such additional patch is necessary: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=read-minibuffer-restore-windows-exit-minibuffer.patch diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 3751ba80e0..40454eed23 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2319,6 +2333,10 @@ exit-minibuffer (error "%s" "Not in most nested command loop")) (when (not (innermost-minibuffer-p)) (error "%s" "Not in most nested minibuffer"))) + ;; When read_minibuf doesn't restore all previous windows, + ;; then at least pop down the completions window. + (unless read-minibuffer-restore-windows + (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. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 04 02:52:37 2021 Received: (at 45072) by debbugs.gnu.org; 4 Aug 2021 06:52:37 +0000 Received: from localhost ([127.0.0.1]:42301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBAlZ-000252-2h for submit@debbugs.gnu.org; Wed, 04 Aug 2021 02:52:37 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBAlX-00024p-Cd for 45072@debbugs.gnu.org; Wed, 04 Aug 2021 02:52:36 -0400 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=6dVZHodNOgIadtiTJmBSGafQokZ6ZnyRe671RlKYl78=; b=uVQ88WN6BvO1rep8rvJ7lCvNxT t9FcbYX3yX3DQ9mR1x6zMdEaUXKAPWJlP9fLXhkMTS86UaKOpY87ufUX126WVSdEzIBoZxMFwBAn0 q7ZU58yIC1qIPmXdN3X1+Pyd9TCuYDa0rGvfBuJ8ynaBLp7/CsPv7BUBGju5MJ79IeeE=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBAlN-0004aj-TZ; Wed, 04 Aug 2021 08:52:28 +0200 From: Lars Ingebrigtsen To: Juri Linkov 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> <87fsvr55n7.fsf@linkov.net> Date: Wed, 04 Aug 2021 08:52:25 +0200 In-Reply-To: <87fsvr55n7.fsf@linkov.net> (Juri Linkov's message of "Tue, 03 Aug 2021 10:57:04 +0300") Message-ID: <87im0lhfbq.fsf@gnus.org> 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: Juri Linkov writes: >> + 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 (th [...] 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: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: martin rudalics , Eli Zaretskii , bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: >> + 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 = true; > > I recommend to install this patch. Maybe it's not perfect, but works > reasonably well, and there is the high demand for this feature. Oh, I didn't realise that it hadn't been applied already, so I redid it for the current trunk and tested it, and it seems to work as expected, so I went ahead and pushed it. > Only such additional patch is necessary: [...] > + ;; When read_minibuf doesn't restore all previous windows, > + ;; then at least pop down the completions window. > + (unless read-minibuffer-restore-windows > + (minibuffer-hide-completions)) Hm... Well, I guess that's what most people would want... but... should it be user-controllable? Perhaps read_minibuffer_restore_windows shouldn't be a boolean, but allow values like t, 'completions and nil, where 'completions would trigger this behaviour? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 04 04:46:42 2021 Received: (at 45072) by debbugs.gnu.org; 4 Aug 2021 08:46:42 +0000 Received: from localhost ([127.0.0.1]:42703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBCXy-00071D-0z for submit@debbugs.gnu.org; Wed, 04 Aug 2021 04:46:42 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:58393) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBCXw-0006v3-Dx for 45072@debbugs.gnu.org; Wed, 04 Aug 2021 04:46:40 -0400 Received: (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A24656000D; Wed, 4 Aug 2021 08:46:32 +0000 (UTC) From: Juri Linkov To: Lars Ingebrigtsen 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> <87fsvr55n7.fsf@linkov.net> <87im0lhfbq.fsf@gnus.org> Date: Wed, 04 Aug 2021 11:39:04 +0300 In-Reply-To: <87im0lhfbq.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 04 Aug 2021 08:52:25 +0200") Message-ID: <87czqtbo47.fsf@mail.linkov.net> 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 , Eli Zaretskii , bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> + ;; When read_minibuf doesn't restore all previous windows, >> + ;; then at least pop down the completions window. >> + (unless read-minibuffer-restore-windows >> + (minibuffer-hide-completions)) > > Hm... Well, I guess that's what most people would want... but... The new option read-minibuffer-restore-windows is quite unusable without the above change: selecting a completion from the completions buffer will leave the completions buffer on the screen. > should it be user-controllable? Perhaps read_minibuffer_restore_windows > shouldn't be a boolean, but allow values like t, 'completions and nil, > where 'completions would trigger this behaviour? Then I propose a new hook, e.g. read-minibuffer-restore-functions with the default value '(minibuffer-hide-completions). Then such hook could be run instead of restoring the window configuration, i.e. the logic could be: if (read_minibuffer_restore_windows) record_unwind_protect (restore_window_configuration, list3 (Fcurrent_window_configuration (Qnil), Qt, Qt)); else safe_run_hooks (Qread_minibuffer_restore_functions); From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 04 04:57:04 2021 Received: (at 45072) by debbugs.gnu.org; 4 Aug 2021 08:57:04 +0000 Received: from localhost ([127.0.0.1]:42741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBCi0-00082H-LF for submit@debbugs.gnu.org; Wed, 04 Aug 2021 04:57:04 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBChy-00081n-TM for 45072@debbugs.gnu.org; Wed, 04 Aug 2021 04:57:03 -0400 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=VcyhDZ1MzA/tPW+YbY7/1SWlI5cLUrPCLQFvUj397r0=; b=NOPTjcyWMHhg481QCs4RHzDO5S GJiJ1hsSFfCXPs8aGi/Xrdka5QDqPRXZewvMYECTAZaAJCSVFKSBoita/Y6koYBqD81iOMEfqROL5 rTLZYKcPOizupISyvP4ulqeDWDWk7atF2rY37rC0N+dMQ64WPebvJv4G997rEzxSNt4U=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBChp-0005qb-RM; Wed, 04 Aug 2021 10:56:56 +0200 From: Lars Ingebrigtsen To: Juri Linkov 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> <87fsvr55n7.fsf@linkov.net> <87im0lhfbq.fsf@gnus.org> <87czqtbo47.fsf@mail.linkov.net> Date: Wed, 04 Aug 2021 10:56:53 +0200 In-Reply-To: <87czqtbo47.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 04 Aug 2021 11:39:04 +0300") Message-ID: <87lf5hlh9m.fsf@gnus.org> 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: Juri Linkov writes: >>> + ; ; When read_minibuf doesn't restore all previous windows, >>> + ;; then at least pop down the completions window. >>> + (unless read-minibuffer-restore-windows >>> + (minibuffer-hide-completion [...] 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: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: martin rudalics , Eli Zaretskii , bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: >>> + ;; When read_minibuf doesn't restore all previous windows, >>> + ;; then at least pop down the completions window. >>> + (unless read-minibuffer-restore-windows >>> + (minibuffer-hide-completions)) >> >> Hm... Well, I guess that's what most people would want... but... > > The new option read-minibuffer-restore-windows is quite unusable > without the above change: selecting a completion from the > completions buffer will leave the completions buffer on the screen. Yes. But I think some people would want that -- that is, they might be `C-g'-ing out of the minubuffer just because they want to copy some of the text in the completions buffer. But on the other hand, that may be such a rare thing to do that just applying your proposed patch is the right thing, and then we could just see whether anybody actually requests that before tinkering any further with it... So... I think you should just push the patch, and then we'll see. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 04 16:31:25 2021 Received: (at 45072) by debbugs.gnu.org; 4 Aug 2021 20:31:25 +0000 Received: from localhost ([127.0.0.1]:45250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBNXw-0001IV-Lw for submit@debbugs.gnu.org; Wed, 04 Aug 2021 16:31:24 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:56227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBNXv-0001I6-7Y for 45072@debbugs.gnu.org; Wed, 04 Aug 2021 16:31:23 -0400 Received: (Authenticated sender: juri@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 52D00E0005; Wed, 4 Aug 2021 20:31:13 +0000 (UTC) From: Juri Linkov To: Lars Ingebrigtsen 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> <87fsvr55n7.fsf@linkov.net> <87im0lhfbq.fsf@gnus.org> <87czqtbo47.fsf@mail.linkov.net> <87lf5hlh9m.fsf@gnus.org> Date: Wed, 04 Aug 2021 23:17:20 +0300 In-Reply-To: <87lf5hlh9m.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 04 Aug 2021 10:56:53 +0200") Message-ID: <87r1f976rr.fsf@mail.linkov.net> 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 , Eli Zaretskii , bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>>> + ;; When read_minibuf doesn't restore all previous windows, >>>> + ;; then at least pop down the completions window. >>>> + (unless read-minibuffer-restore-windows >>>> + (minibuffer-hide-completions)) >>> >>> Hm... Well, I guess that's what most people would want... but... >> >> The new option read-minibuffer-restore-windows is quite unusable >> without the above change: selecting a completion from the >> completions buffer will leave the completions buffer on the screen. > > Yes. But I think some people would want that -- that is, they might be > `C-g'-ing out of the minubuffer just because they want to copy some of > the text in the completions buffer. > > But on the other hand, that may be such a rare thing to do that just > applying your proposed patch is the right thing, and then we could just > see whether anybody actually requests that before tinkering any further > with it... > > So... I think you should just push the patch, and then we'll see. Actually, my previous patch doesn't handle the case of `C-g'-ing out of the minubuffer. It hides the completions buffer only after exiting in the normal way by RET. But fortunately there is an existing hook 'minibuffer-exit-hook' called in both cases of exiting by `C-g' and RET. And the users can easily change it, e.g. to not pop down the *Completions* buffer, or to remove more windows, etc. diff --git a/etc/NEWS b/etc/NEWS index f0fa686bc9..cca6956275 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -180,6 +180,8 @@ nor t. +++ ** New user option 'read-minibuffer-restore-windows'. +When customized to nil, it uses 'minibuffer-restore-windows' in +'minibuffer-exit-hook' to remove only the *Completions* window. +++ ** New system for displaying documentation for groups of functions. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 3751ba80e0..79fb7e6afc 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2328,6 +2342,16 @@ exit-minibuffer (setq deactivate-mark nil) (throw 'exit nil)) +(defun minibuffer-restore-windows () + "Restore some windows on exit from minibuffer. +When `read-minibuffer-restore-windows' is nil, then this function +added to `minibuffer-exit-hook' will remove at least the window +with the *Completions* buffer." + (unless read-minibuffer-restore-windows + (minibuffer-hide-completions))) + +(add-hook 'minibuffer-exit-hook 'minibuffer-restore-windows) + (defun minibuffer-quit-recursive-edit () "Quit the command that requested this recursive edit without error. Like `abort-recursive-edit' without aborting keyboard macro diff --git a/src/minibuf.c b/src/minibuf.c index 3ee0dca5e0..a054f0e20d 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -2535,8 +2535,11 @@ syms_of_minibuf (void) 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. */); +the associated minibuffer window. + +If this is nil, no such restorations are done. +But still `minibuffer-restore-windows' in `minibuffer-exit-hook' +will remove the window with the *Completions* buffer. */); read_minibuffer_restore_windows = true; defsubr (&Sactive_minibuffer_window); From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 05 06:55:29 2021 Received: (at 45072) by debbugs.gnu.org; 5 Aug 2021 10:55:29 +0000 Received: from localhost ([127.0.0.1]:46025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBb29-00065G-A0 for submit@debbugs.gnu.org; Thu, 05 Aug 2021 06:55:29 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBb27-000653-47 for 45072@debbugs.gnu.org; Thu, 05 Aug 2021 06:55:28 -0400 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=89hqyDuMuPAmwbzOtRy3F4RAm6x92L3lZ2T3eNEDKn4=; b=uPbvZS21cvvwQ3T7TNAPorcQ0/ Lh6Ie7GH0wN4jGUKbVKGOS3HLwfRhgfl0sXqmtvSbxUcWY+sKmDXm3DZKN4R/qkSOfeBvCbMGTJB8 BKHV4Aftlkbu2EUY0E4hqTK7hCSyfVNzkhZaHtksLg4Kp/zg6CNBBTm343TfD+FR4qiY=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBb1x-0002la-9S; Thu, 05 Aug 2021 12:55:19 +0200 From: Lars Ingebrigtsen To: Juri Linkov 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> <87fsvr55n7.fsf@linkov.net> <87im0lhfbq.fsf@gnus.org> <87czqtbo47.fsf@mail.linkov.net> <87lf5hlh9m.fsf@gnus.org> <87r1f976rr.fsf@mail.linkov.net> Date: Thu, 05 Aug 2021 12:55:16 +0200 In-Reply-To: <87r1f976rr.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 04 Aug 2021 23:17:20 +0300") Message-ID: <87eeb8i2jv.fsf@gnus.org> 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: Juri Linkov writes: > But fortunately there is an existing hook 'minibuffer-exit-hook' > called in both cases of exiting by `C-g' and RET. > And the users can easily change it, e.g. to not pop down > the *Completions* bu [...] 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: -2.3 (--) X-Debbugs-Envelope-To: 45072 Cc: martin rudalics , Eli Zaretskii , bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > But fortunately there is an existing hook 'minibuffer-exit-hook' > called in both cases of exiting by `C-g' and RET. > And the users can easily change it, e.g. to not pop down > the *Completions* buffer, or to remove more windows, etc. Looks good to me (but I haven't actually tried the patch). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 05 19:40:55 2021 Received: (at 45072) by debbugs.gnu.org; 5 Aug 2021 23:40:55 +0000 Received: from localhost ([127.0.0.1]:48634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBmyt-0000mj-LT for submit@debbugs.gnu.org; Thu, 05 Aug 2021 19:40:55 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:37783) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBmys-0000mE-Af; Thu, 05 Aug 2021 19:40:54 -0400 Received: (Authenticated sender: juri@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id B758B240003; Thu, 5 Aug 2021 23:40:45 +0000 (UTC) From: Juri Linkov To: Lars Ingebrigtsen 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@protected.rcdrun.com> <87eek1fvgf.fsf@gnus.org> <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87lfe8jsok.fsf@gnus.org> <83h7ow70ty.fsf@gnu.org> <7a7c3ef0-619d-cd76-a4e4-040009e33d75@gmx.at> <87fsvr55n7.fsf@linkov.net> <87im0lhfbq.fsf@gnus.org> <87czqtbo47.fsf@mail.linkov.net> <87lf5hlh9m.fsf@gnus.org> <87r1f976rr.fsf@mail.linkov.net> <87eeb8i2jv.fsf@gnus.org> Date: Fri, 06 Aug 2021 02:36:53 +0300 In-Reply-To: <87eeb8i2jv.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 05 Aug 2021 12:55:16 +0200") Message-ID: <877dgzcvl6.fsf@mail.linkov.net> 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 , Eli Zaretskii , bugs@gnu.support, 45072@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) tags 45072 fixed close 45072 28.0.50 quit >> But fortunately there is an existing hook 'minibuffer-exit-hook' >> called in both cases of exiting by `C-g' and RET. >> And the users can easily change it, e.g. to not pop down >> the *Completions* buffer, or to remove more windows, etc. > > Looks good to me (but I haven't actually tried the patch). So now pushed and this request is closed. From unknown Sun Aug 17 04:16:09 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 03 Sep 2021 11:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator