From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Wed, 25 Nov 2020 21:09:47 +0000 Message-ID: <20201125210947.GB8228@ACM> References: <20201123133613.GA4635@ACM> <69ba00e6-b182-77e1-911b-d70f9fffa762@gmx.at> <20201123160703.GB4635@ACM> <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26206"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Gregory Heytings , Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 25 22:10:30 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ki23Z-0006jN-WF for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Nov 2020 22:10:30 +0100 Original-Received: from localhost ([::1]:54014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki23Y-0003Qa-Vf for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Nov 2020 16:10:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki231-00030y-Kn for emacs-devel@gnu.org; Wed, 25 Nov 2020 16:09:55 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:22255 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1ki22x-0007uY-C1 for emacs-devel@gnu.org; Wed, 25 Nov 2020 16:09:55 -0500 Original-Received: (qmail 68044 invoked by uid 3782); 25 Nov 2020 21:09:47 -0000 Original-Received: from acm.muc.de (p4fe15c9a.dip0.t-ipconnect.de [79.225.92.154]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Wed, 25 Nov 2020 22:09:47 +0100 Original-Received: (qmail 14118 invoked by uid 1000); 25 Nov 2020 21:09:47 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259812 Archived-At: Hello, Martin. On Wed, Nov 25, 2020 at 10:25:46 +0100, martin rudalics wrote: > > Fine. I will push this to Emacs 27.2. > Done. Alan, the following two concerns are still awaiting a fix: OK. > Madhu's: > These patches introduce a regression on "graphical" emacs - > 1. emacs -Q > 2. M-: (setq pop-up-frames 'graphic-only) > 3. M-! g > This should pop up a *Completions* buffer in a new frame. > On choosing the completion (via a button1 or by navigating to the > desired point and typing RET) - the frame should be automatically > hidden[1] > This doesn't happen anymore and the completion buffer and frame remain > there taking up focus. I've started looking at this. It could take some time to resolve. > [1] default value for frame-auto-hide-function is #'iconify-frame, but > if your window manager cannot iconify it, set > (setq frame-auto-hide-function #'delete-frame) > Andrii's: > It is not producing bugs for me, but changes behavior. This is inevitable, even if regrettable. > E.g. in emacs -Q: > 1. Evaluate > (select-frame-set-input-focus > (make-frame '((minibuffer . only) > (left . 1.0)))) > 2. M-x > 3. C-x 5 o > Before minibuffer-follows-selected-frame, the prompt stays in the > minibuffer-only frame. > On recent master, the prompt is moved to other frame leaving > minibuffer-only frame empty. I can't report this as a bug. Just > wondering why minibuffer-follows-selected-frame is set to t by default, > potentially changing someone's expected behavior. The behaviour in Emacs 27 is chaotic. Sometimes a minibuffer moves with a frame switch, sometimes it doesn't. The change in master is intended to make the behaviour logical and systematic. As to why minibuffer-follows-selected-frame is t by default, there is no particular reason. It transpired that Eli and I had different mental models of the connection between minibuffers and frames. The setting t represents Eli's model rather than mine (?ours). Setting it to nil by default would also cause annoyance, in different ways. Also, how often do people actually select minibuffer-only frames? Unless I'm missing something, it seems a rather strange thing to want to do. > martin -- Alan Mackenzie (Nuremberg, Germany).