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#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Date: Sun, 11 Jun 2023 16:01:18 +0000 Message-ID: References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> 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="32209"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "al@petrofsky.org" , "rudalics@gmx.at" , Eli Zaretskii , "monnier@iro.umontreal.ca" , "63967@debbugs.gnu.org" <63967@debbugs.gnu.org> To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 11 18:02:41 2023 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 1q8NWa-0008EC-VW for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Jun 2023 18:02:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q8NWB-00074L-3L; Sun, 11 Jun 2023 12:02:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8NVz-00072l-4W for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 12:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q8NVy-0000jK-QN for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 12:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q8NVy-0007jA-Ls for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 12:02: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: Sun, 11 Jun 2023 16:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs Original-Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168649928829634 (code B ref 63967); Sun, 11 Jun 2023 16:02:02 +0000 Original-Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 16:01:28 +0000 Original-Received: from localhost ([127.0.0.1]:37639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8NVQ-0007ht-0a for submit@debbugs.gnu.org; Sun, 11 Jun 2023 12:01:28 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:57028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8NVN-0007he-Jx for 63967@debbugs.gnu.org; Sun, 11 Jun 2023 12:01:26 -0400 Original-Received: (qmail 76409 invoked by uid 3782); 11 Jun 2023 18:01:19 +0200 Original-Received: from acm.muc.de (pd953a4c0.dip0.t-ipconnect.de [217.83.164.192]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 Jun 2023 18:01:19 +0200 Original-Received: (qmail 11703 invoked by uid 1000); 11 Jun 2023 16:01:18 -0000 Content-Disposition: inline In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263251 Archived-At: Hello, Drew. On Sun, Jun 11, 2023 at 14:35:59 +0000, Drew Adams wrote: > > > > Perhaps we should modify the minibuffer code > > > > to note which window should be current after > > > > the completion or abortion of the minibuffer > > > > read action. > > > Isn't that simply "the window which was selected > > > before entering the minibuffer"? > > Most of the time, yes. If that window no longer > > exists on termination of the minibuffer, or we've > > moved to a different frame, things aren't so simple. > You can and will ignore this, .... I'm answering your post. ;-) > .... but IMO _all_ of the above is misguided and short-sighted. "Isn't > that simply...?" is just plain wrong - both the question and any single > answer. > It isn't "simply" _anything_ you can preconceive. > It's _whichever window ended up_ selected after > using the minibuffer. Nothing more, nothing less. That window is the miniwindow. Unless we're talking about a recursive minibuffer use from the miniwindow, we need to select some other window after using the minibuffer, otherwise the user would need explicitly to select a window herself. > Let's-hard-code-which-window-should-be-selected > is maybe related to the fact that I can no longer > use Emacs > 26.3. > What's wrong with attempts to predetermine which > window should be selected after a minibuffer > read? > It's the presumption that a minibuffer's only > purpose is to return something read, and that the > state of Emacs, including which windows exist and > which should be selected, should be the same as > before the minibuffer was entered - or should be > any other predefined state. The selected window > here shouldn't be determined formulaically. It needs to be determined somehow. That "somehow" would probably count as a formula in some sense. > This completely prevents or interferes with code > that _does things_ while the minibuffer is active > with the intent of changing such state, e.g., the > intent to change the selected window, and not > just till minibuffer reading is finished. If you do C-x C-f, do wierd and wonderful things whilst the minibuffer is active, then select a file to vist, you seem to be saying you want that file to be visited on what became the selected window just before terminating the minibuffer. Am I right, here? If so, that would involve some new options to enable this behaviour, and some new complications in the code to support it. > There. I've said it again. And clearly Emacs > won't be going back to its former freedom in > this regard - 1000 ships have sailed. But IMO > this is a great loss. And it comes, I think, > from assuming that others use existing behavior > only the way you do. As one of the people who implemented a recent change in the minibuffer, I'm not sure this is entirely fair. Efforts were made to avoid restricting the ways the minibuffer could be used. The code is anything but simple and straightforward. It might be useful to compare with the way most non-Emacs systems cope with these problems: they use what are known as "modal" dialogue boxes. Having initiated one of these, there is no way of doing anything else in the system, including looking at a buried frame, until the "modal" dialogue has been terminated or aborted. I think Emacs's way is better, even if not perfect. > My use of Emacs relies on doing lots of things > while a minibuffer is active - including things > that you might do only when it's inactive. And > the changes I make while its active shouldn't > be overridden when a minibuffer is exited. That is complicated to specify and implement. > And yes, this can include changing the selected > window and focused frame. I want to be able to > do that myself, interactively or by definition > from the function that invoked the minibuffer. The command using the minibuffer often acts on a buffer, window, and/or frame. In such cases, chaos could result from having a different current buffer, selected window, or selected frame from what the command thinks it has. It is possible that such chaos was what prompted the restoration of the window configuration, etc., after using the minibuffer. I've had a look into git blame minibuf.c, and it would appear that the use of set-window-configuration is very old indeed - there is a comment by Richard Stallman from 1996-04-07 saying: /* We have to do this after saving the window configuration since that is what restores the current buffer. */ .. > To my mind you've hobbled Emacs - specifically > its minibuffer, just as much as if you'd poked > out its eyes or cut off its legs. I assure you there was no malice intended. ;-) > If you'd really wanted to provide only some > _default_ behavior wrt choosing the window to > select here, then you'd have done that. You'd > have provided some way (e.g., a variable) for > code to _prevent_ force-selecting the window > you've predetermined to be the "chosen one". As remarked above, some window has to be selected (? "force-selected"), otherwise point would remain in the miniwindow. That window needs to be determined somehow. > The Emacs minibuffer was "simply" better > before you simply "fixed" it. There were things wrong with it, which have been fixed. You have mentioned version 26.3 as the latest one you can use. Are you saying that the minibuffer was fine for you at that release, or was it better even earlier? -- Alan Mackenzie (Nuremberg, Germany).