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.bugs Subject: bug#48674: Frames and minibuffer bug Date: Thu, 27 May 2021 20:01:19 +0000 Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@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="19039"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48674@debbugs.gnu.org, Iris =?UTF-8?Q?Garc=C3=ADa?= To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 27 22:02:41 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmMDJ-0004op-3I for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 May 2021 22:02:41 +0200 Original-Received: from localhost ([::1]:52602 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmMDH-0002d3-Dp for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 May 2021 16:02:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmMCg-0002bg-9t for bug-gnu-emacs@gnu.org; Thu, 27 May 2021 16:02:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41311) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmMCg-0001GW-0W for bug-gnu-emacs@gnu.org; Thu, 27 May 2021 16:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lmMCf-0001V5-UZ for bug-gnu-emacs@gnu.org; Thu, 27 May 2021 16:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 May 2021 20:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48674 X-GNU-PR-Package: emacs Original-Received: via spool by 48674-submit@debbugs.gnu.org id=B48674.16221456905726 (code B ref 48674); Thu, 27 May 2021 20:02:01 +0000 Original-Received: (at 48674) by debbugs.gnu.org; 27 May 2021 20:01:30 +0000 Original-Received: from localhost ([127.0.0.1]:52857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmMC9-0001UI-Pp for submit@debbugs.gnu.org; Thu, 27 May 2021 16:01:30 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:10195 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lmMC7-0001Tz-FV for 48674@debbugs.gnu.org; Thu, 27 May 2021 16:01:28 -0400 Original-Received: (qmail 65627 invoked by uid 3782); 27 May 2021 20:01:20 -0000 Original-Received: from acm.muc.de (p4fe1599a.dip0.t-ipconnect.de [79.225.89.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 27 May 2021 22:01:20 +0200 Original-Received: (qmail 8451 invoked by uid 1000); 27 May 2021 20:01:19 -0000 Content-Disposition: inline In-Reply-To: <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:207396 Archived-At: Hello, Martin. On Thu, May 27, 2021 at 18:33:45 +0200, martin rudalics wrote: > > What is happening is that the with-selected-frame invocation is > > selecting (temporarily) a different frame from the minibuffer's > > frame. This has the (intended) side effect of making the MB no > > longer selected in that frame. When the MB's frame becomes selected > > again, nothing makes the mini-window the selected window. This > > needs fixing. > Does this mean that the > Fselect_window (f->selected_window, norecord); > in do_switch_frame fails? If so, why? For some values of "fails", yes. When we're in frame F1's minibuffer, and do (with-selected-frame F2 (foo)): (i) Frame F2 becomes selected. (ii) The current window in F1 ceases to be the mini-window, becoming some other window. (iii) The minibuffer is moved from F1 to F2. (iv) We evaluate (foo). (v) Frame F1 becomes selected again. (vi) The current window in F1 doesn't revert to being the mini-window. > Do we anywhere violate the > (eq (selected-window) (frame-selected-window (selected-frame))) > invariant? No. The variables selected-\(window\|frame\) are not set directly anywhere in minibuf.c, only by calling functions like Fselect_window. > That might be fatal. Both, `with-selected-frame' and > `with-selected-window', should leave no traces behind. This is what has preoccupied me over the last few hours. It seems we want do_switch_frame to do different things for (i) a "permanent" frame switch (e.g. C-x 5 o) and (i) a "temporary" frame switch (e.g. with-selected-frame). If the selected window in F1 is the mini-window, we want it to select a different window in (i), but stay the same in (ii). Or perhaps we want a variant of select-frame which wouldn't move a stack of minibuffers from F1 to F2. Something like Ftemporarily_select_frame, which would come with discouragement from use in its doc string, and wouldn't be interactive. with-selected-frame would use this. Something like (untested): DEFUN ("temporarily-select-frame", Ftemporarily_select_frame, Stemporarily_select_frame, 1, 1, null, doc: /* Temporarily select FRAME. More doc string....... This function returns FRAME, or nil if FRAME has been deleted. */) (Lisp_Object frame) { struct frame *f; CHECK_LIVE_FRAME (frame); f = XFRAME (frame); if (FRAME_TOOLTIP_P (f)) /* Do not select a tooltip frame (Bug#47207). */ error ("Cannot select a tooltip frame"); else return do_switch_frame (frame, 1, 0, Qt, 1); <==== Extra argument here. } (This is all with minibuffer-follows-selected-frame set to t.) > > Martin, that Qt in the Fselect_window call (the NORECORD argument) - > > would it be perhaps be better as Qnil? > > diff --git a/src/minibuf.c b/src/minibuf.c > > index cffb7fe787..3468643a7e 100644 > > --- a/src/minibuf.c > > +++ b/src/minibuf.c > > @@ -893,6 +893,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > > > > run_hook (Qminibuffer_setup_hook); > > > > + /* If the above hook has made the mini-window no longer the selected > > + window, restore it. */ > > + if (!EQ (selected_window, minibuf_window)) > > + Fselect_window (minibuf_window , Qt); > > + > Are we sure that we want to disallow a function on > `minibuffer-setup-hook' to change the selected window? With Emacs 27 > (defun foo () > (select-window (frame-first-window))) > (add-hook 'minibuffer-setup-hook 'foo) > works without any problems here. Are you sure? For me, that setup makes C-x C-f open a minibuffer, but leave point in the same window, not the miniwindow. That was a quick try with the emacs-27 branch, not Emacs 27.{1,2}, and was on a GUI. I think we should disallow selecting windows in minibuffer-setup-hook. This hook is run after the mini-window has been selected in read_minibuf, just before the recursive edit. > The NORECORD argument is important only if you need it - so far, the > previous buffers of the minibuffer window were largely ignored. Thanks. I'll think about that when my head's a bit clearer. > martin