From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 19:12:37 +0300 Message-ID: <83sfayx9je.fsf@gnu.org> References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3943"; mail-complaints-to="usenet@ciao.gmane.io" Cc: al@petrofsky.org, acm@muc.de, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org, rudalics@gmx.at To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 11 18:13:20 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 1q8Ngu-0000qR-EU for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Jun 2023 18:13:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q8Nge-0007xA-29; Sun, 11 Jun 2023 12:13:04 -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 1q8Ngc-0007x0-F0 for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 12:13:02 -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 1q8Ngc-0002TL-6f for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 12:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q8Ngb-0007zH-L2 for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 12:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jun 2023 16:13:01 +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.168649995630669 (code B ref 63967); Sun, 11 Jun 2023 16:13:01 +0000 Original-Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 16:12:36 +0000 Original-Received: from localhost ([127.0.0.1]:37649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8NgC-0007yb-0Y for submit@debbugs.gnu.org; Sun, 11 Jun 2023 12:12:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8Ng9-0007yN-RY for 63967@debbugs.gnu.org; Sun, 11 Jun 2023 12:12:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8Ng1-0002Qn-Ol; Sun, 11 Jun 2023 12:12:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zRH5jLx8Ojgmg9at4R0iSe4k/dRKYKuFpQPNY9Yhx4s=; b=EgqrwDeMGhKB ez15F7cmyqm0f5851afSCowxfyfi8S3UyOmIwjXUhhjbOjKTPsRqUuM96PAPtgihVhskRu7cixb5H W52j753efTWoPSE1ZIMiflmRUazOgy1Oh/LC9XBoHpuKVOk7oOZ0u31DPyloKHrsuT1qnWqqX7BcY jGKWwzLm/iS5eQxSFu2djE8eeN6pEkyELT82T6Atcqzis6g0L6m1jwWsjY5s6mBAhHtcO5Vq3B9Py PF/rw0GHD9OAQszcQJQAsr/l5jDm3ai/FCyNFcB3ongIf6Rq9hZDPauskGob5po95L8uF5sQzCrfg zcRWxCrhx5mjiaTmN68nXQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8Ng1-0005T7-8c; Sun, 11 Jun 2023 12:12:25 -0400 In-Reply-To: (message from Drew Adams on Sun, 11 Jun 2023 14:35:59 +0000) 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:263253 Archived-At: > From: Drew Adams > CC: "al@petrofsky.org" , > "rudalics@gmx.at" > , > "monnier@iro.umontreal.ca" , > "63967@debbugs.gnu.org" <63967@debbugs.gnu.org> > Date: Sun, 11 Jun 2023 14:35:59 +0000 > > > > > 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, 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. I will indeed ignore most of what you say -- because you seem to completely misunderstand what this discussion is about. See below. > It isn't "simply" _anything_ you can preconceive. > It's _whichever window ended up_ selected after > using the minibuffer. Nothing more, nothing less. Using the minibuffer doesn't by itself cause any window to be selected. Using the minibuffer just supplies to whatever command that prompted the user with the response to the prompt. Then the minibuffer is exited, and only then the command continues its execution, and could very well choose another window to be the selected one. This discussion is about what happens _immediately_ after read-from-minibuffer exits, which just provides the response to the prompt. It has nothing to do with what you are talking about, and doesn't affect the window that will be the selected one after the command exits. read-from-minibuffer invokes recursive-editing cycle. When that cycle ends, it should leave the window/frame configuration intact, or as intact as possible. Why? because most commands that invoke read-from-minibuffer in its interactive form do not expect the window configuration to change after the interactive form finishes its job. And if you still don't agree, then let's agree to disagree.