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#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Mon, 11 Jul 2022 16:22:21 +0000 Message-ID: References: <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> <61fe102b-eec2-9711-560e-c141ed3cc6e4@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8749"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56305@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca, acm@muc.de To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 11 18:39:55 2022 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 1oAwRu-0002Ac-9z for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Jul 2022 18:39:54 +0200 Original-Received: from localhost ([::1]:44420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oAwRt-0006gm-0W for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Jul 2022 12:39:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAwBb-0000iK-Ky for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2022 12:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46943) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oAwBb-0007k4-BJ for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2022 12:23:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oAwBa-0005ZQ-60 for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2022 12:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Jul 2022 16:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56305 X-GNU-PR-Package: emacs Original-Received: via spool by 56305-submit@debbugs.gnu.org id=B56305.165755655121357 (code B ref 56305); Mon, 11 Jul 2022 16:23:02 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 11 Jul 2022 16:22:31 +0000 Original-Received: from localhost ([127.0.0.1]:40840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oAwB4-0005YO-Px for submit@debbugs.gnu.org; Mon, 11 Jul 2022 12:22:31 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61009 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1oAwB2-0005Y6-Kv for 56305@debbugs.gnu.org; Mon, 11 Jul 2022 12:22:29 -0400 Original-Received: (qmail 86338 invoked by uid 3782); 11 Jul 2022 16:22:22 -0000 Original-Received: from acm.muc.de (p4fe15cf0.dip0.t-ipconnect.de [79.225.92.240]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 11 Jul 2022 18:22:21 +0200 Original-Received: (qmail 7553 invoked by uid 1000); 11 Jul 2022 16:22:21 -0000 Content-Disposition: inline In-Reply-To: <61fe102b-eec2-9711-560e-c141ed3cc6e4@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:236701 Archived-At: Hello, Martin. On Mon, Jul 11, 2022 at 09:45:59 +0200, martin rudalics wrote: > > Thanks! I use xfce, too. But I haven't changed anything here away from > > its default. I run Emacs on a tty anyway. > So you implemented 'minibuffer-follows-selected-frame' despite the fact > that multiple frames hardly make sense on your usual setup? That's not a fact. I typically run with several/many frames on my tty. Six, or even nine, is not uncommon. I switch between them using the keys. The minibuffer not staying in "its own" frame was annoying me quite a bit. > >> Now note that when in my scenario I type C-x C-c, the minibuffer frame > >> is selected and has focus. > > But not raised, though? Surely the MB frame being selected and having > > focus is what we want, so that we can type "yes" or "no" next. > With "when" I meant "at the time" I type C-x C-c. Sorry for the misunderstanding. > > Try running GDB in an Emacs on a Linux tty. That's what I do anyway. I > > seem to remember watching the focus, last time I did this, a day or two > > ago. > I have no experience with running GDB from anywhere but Emacs itself. > IIRC Linux ttys are full-screen, so where would my Emacs frames fit in? The GDB Emacs is on a tty, in a single frame. The frames of the target Emacs can be on X Windows. (Or in another tty.) So you would start the target Emacs in X, note its process-id with ps a, start gdb in the tty Emacs, then do attach , and carry on as usual. When you reach a breakpoint, the X session appears to hang, at which point you type -- (for example) to get to the Emacs and GDB. When you type continue in GDB, you then return to X with (e.g.) -. It's not as cumbersome as it sounds. > > Anyway, we'll have to decide soon what to do for Emacs 28.2. The > > first pretest is already out there. What we do needs to be simple > > and safe. The alternatives so far seem to be do nothing, apply the > > 53-line deletion from master (which Eli has already rejected) or > > apply my patch above (fixed to work with tty's). At the moment, I > > would favour the last of these. > For Emacs 28.2 I could imagine something like > diff --git a/src/frame.c b/src/frame.c > index 0c278259a7..27442ee120 100644 > --- a/src/frame.c > +++ b/src/frame.c > @@ -1499,7 +1499,8 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor > #else /* ! 0 */ > /* Instead, apply it only to the frame we're pointing to. */ > #ifdef HAVE_WINDOW_SYSTEM > - if (track && FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->get_focus_frame) > + if (track && NILP (Vinhibit_redisplay) > + && FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->get_focus_frame) > { > Lisp_Object focus, gfocus; > that is use the analogous unpleasant hack from resize_mini_window. I tried it out. It appears to work. :-) > > select-window and select-frame should NOT move the focus. > I'd like to agree with you but implementing it is virtually impossible. > Emacs would probably stop working immediately. Just try to tell people > that 'select-window' will not give input focus to a window only because > it happens to reside on another frame. Apologies: the doc string for select-window virtually says it grabs the focus. Couldn't we go the whole way, and explicitly state that select-window is really "select-window-set-input-focus"? > > select-frame is even documented (in the Elisp manual) not to do > > this. That documentation is not true for Emacs 28.x, but may now > > have become true in master since I removed those 53 lines from > > do_switch_frame, but I'm not sure. > The Elisp manual is controversial about this. A sentence like > Note that sometimes selecting a window is not enough to show it, or > make its frame the top-most frame on display: you may also need to > raise the frame or make sure input focus is directed to that frame. That sounds like the text from a bug report. Selecting a window should either do all these GUI things, or it shouldn't do them. "Sometimes" feels like an apology for failing to fix a bug before a release. > wouldn't make sense if in a majority of cases selecting a window would > _not_ also raise its frame and direct input focus to it. So why can't we make select-window _always_ raise its frame and get input focus? Perhaps we would also need a (new) function which would just make the struct window * current for manipulation without it being displayed on the screen. That would give us two unambiguously distinct functions for windows, in the same way we have (ought to have) select-frame-set-input-focus and select-frame for frames. Here I advocate amending select-frame such that it _never_ grabs the focus. (Assuming I haven't done that already with that 53-line patch.) > >> Unfortunately, it breaks C-x o. Try with my scenario but instead of > >> answering the 'yes-or-no-p' question type C-x o. With Emacs 28.1 this > >> selects the window on top of the normal frame. With current master it > >> does nothing. > > I don't think that's true. It selects the other window on the normal > > frame (which is the selected frame), but retains the focus in the > > minibuffer frame (the focus being redirected from the normal frame). > Indeed. Which means that it contradicts the Elisp manual which says > about 'select-window' that > This function makes WINDOW the selected window and the window > selected within its frame, and selects that frame. Yes. :-( But that (normal) frame _is_ selected. It's just that its focus has been redirected to the minibuffer frame. Normally, C-x o doesn't move the focus away from the currently focussed frame. > and about the window “selected within the frame” > For the selected frame, that window is > called the “selected window”—the one in which most editing takes place, > and in which the cursor for selected windows appears > Here the cursor for the selected window appears in the minibuffer frame > window and that's what fooled me. In which window should the cursor > appear in your opinion? In the focussed frame, in the selected window in it. That would be in the minibuffer window, surely? I don't think the documentation in the Elisp manual quite covers complexities like MB-only frames and focus redirection. Surely C-x o shouldn't move the focus to a different frame? > >> It doesn't even tell me that there is no other window to select. So > >> this cure is certainly worse than the disease. > > I think that might be over-stating things. Most of the time, users are > > just going to be typing "yes" or "no" here. > Then with > emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" > select the "normal" frame and type C-h f. In the minibuffer frame now > type C-x o. This always used to select _and_ focus the window on the > normal frame and would be needed, for example, to fetch the name of the > function to describe from the normal window. Surely C-x o shouldn't move the focus to a different frame? Here the user would have C-x 5 o to move to that normal frame. Any user chosing a minibuffer-only frame setup (for whatever advantages) should be aware of things like that. > This is the behavior described in the comment your patch elided as > /* If a frame's focus has been redirected toward the currently > selected frame, we should change the redirection to point to the > newly selected frame. This means that if the focus is redirected > from a minibufferless frame to a surrogate minibuffer frame, we > can use `other-window' to switch between all the frames using > that minibuffer frame, and the focus redirection will follow us > around. */ That's a terrible piece of writing. The "using" could mean either of "switch between all the frames which use that MB frame" or "switch between all the frames by using the minibuffer frame as a mechanism". I still can't make sense out of that comment. But the code it was attached to caused the new frame to grab the focus, and that was what happened in the bug scenario. In fact there, the redirection of the new frame (the normal frame) was left pointing at itself. > If we were to change that, we would change the entire cyclic ordering > of windows concept which explicitly states that "If the minibuffer is > active, the minibuffer window is included too" and that window may > reside on any frame. If we change all this (and I think we should), we should do it in a way which doesn't disturb the cyclic ordering. > martin -- Alan Mackenzie (Nuremberg, Germany).