From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Al Petrofsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 04:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 63967@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16862837501388 (code B ref -1); Fri, 09 Jun 2023 04:10:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Jun 2023 04:09:10 +0000 Received: from localhost ([127.0.0.1]:58094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7TR0-0000MF-AC for submit@debbugs.gnu.org; Fri, 09 Jun 2023 00:09:10 -0400 Received: from lists.gnu.org ([209.51.188.17]:51588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7NFo-0006iS-Vt for submit@debbugs.gnu.org; Thu, 08 Jun 2023 17:33:13 -0400 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 1q7NFo-0000qt-P0 for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 17:33:12 -0400 Received: from mail-pl1-f178.google.com ([209.85.214.178]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q7NFn-0001oI-1o for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 17:33:12 -0400 Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1b02fddb908so1324265ad.1 for ; Thu, 08 Jun 2023 14:33:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686259989; x=1688851989; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UXZk86RCRrvdKHdHfSSHnAJfG+IgU4uq6voWSBQl6E4=; b=E7j7i7hqemQ9qHUYZAl5tF3UJHWxpRsBh/KFXcRJ7VMZima1Zx/q7GnLwsqKIookSn +8Ilws4tUnov9aAieiMFdHVaPAJDwNBfuezCSs+iVkIZbS1qmQ2x/7ngzjlLa5MOG7Va zz4oDu9bL/0pSF06FRPW8owlXKyFlqAzxiLqdz20g7GICu4ODQEAcM0fEpLP6mBHRtba vjvq+nIrNyCXeLbQeuM1VegqSQgjp+c/1AeOA/g41PbaB/nEvpdO4sJT8e0dJZLtsY/c psBoqoA+eSxnmq5RQjXFqXenW9KPwF4RZ7wK9G/ANOqaKjxZLYFELd4VHHqsW6h/u1VC i0Gg== X-Gm-Message-State: AC+VfDx+gaxsi+P3xwkllekCyMgpDq3ZV1BkS4PqyuEe9CKbWeGI8Rt8 uuUHATciNDX5siWfXYie+mNz5fpDHQR7KA4Kpyh2kN+badU= X-Google-Smtp-Source: ACHHUZ5xSqDNjiFaMQQV8pueXg9KevbB93a4cfWbYuAzr73kWSWn6yQpTMTEoCPZDAj8FeFZfxoWGqnh9GCUIkI7RtM= X-Received: by 2002:a17:902:d482:b0:1b1:f194:ebb1 with SMTP id c2-20020a170902d48200b001b1f194ebb1mr10539061plg.0.1686259988665; Thu, 08 Jun 2023 14:33:08 -0700 (PDT) MIME-Version: 1.0 From: Al Petrofsky Date: Thu, 8 Jun 2023 17:32:56 -0400 Message-ID: Content-Type: multipart/alternative; boundary="0000000000009f999905fda4ffaa" Received-SPF: pass client-ip=209.85.214.178; envelope-from=al.petrofsky@gmail.com; helo=mail-pl1-f178.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Mailman-Approved-At: Fri, 09 Jun 2023 00:09:05 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --0000000000009f999905fda4ffaa Content-Type: text/plain; charset="UTF-8" While the minibuffer window is active, attempt to switch buffers in an ordinary window like so: emacs -Q M-: (setq enable-recursive-minibuffers t) RET M-x C-x o C-x b foo RET In emacs 27 and earlier, that will switch the buffer in the main window to the new buffer named "foo", but in emacs 28.2, it generates a bogus "user-error: Cannot switch buffers in minibuffer window". I get the same results with -nw. --0000000000009f999905fda4ffaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While the minibuffer window is active, attempt to swi= tch buffers in
an ordinary window like so:

emacs -Q
M-: (setq = enable-recursive-minibuffers t) RET
M-x C-x o C-x b foo RET

In em= acs 27 and earlier, that will switch the buffer in the main
window to th= e new buffer named "foo", but in emacs 28.2, it generates
a bo= gus "user-error: Cannot switch buffers in minibuffer window".
=
I get the same results with -nw.

--0000000000009f999905fda4ffaa-- From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 11:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Al Petrofsky , martin rudalics , Stefan Monnier Cc: 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168630939416384 (code B ref 63967); Fri, 09 Jun 2023 11:17:02 +0000 Received: (at 63967) by debbugs.gnu.org; 9 Jun 2023 11:16:34 +0000 Received: from localhost ([127.0.0.1]:58479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7a6c-0004GC-9z for submit@debbugs.gnu.org; Fri, 09 Jun 2023 07:16:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7a6Z-0004Fw-Nn for 63967@debbugs.gnu.org; Fri, 09 Jun 2023 07:16:32 -0400 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 1q7a6S-0008IY-1k; Fri, 09 Jun 2023 07:16:25 -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=TUtqXOnYZtjbfAEQQDSQMBGaxKQHmjOrjfAUreu/tLQ=; b=XU9BAVud+5U4 yMS0l5r90++VhFM3sW7ck7snuGq13gjQkUyjPrfkPC4028tRUp3+TbQQ+yH7w3xbTdu4nyoWX8uSw XNEItE42xCacqBtY0QZ9jhLnMB8beFmh9fxMU1FLD5X3ByrUdu5AQbD1paz1GIJochG8Zw0jtstMv +dpDOaPm0lmfgOGwA5JEpdTrmf2Fpyjxe/dxHv9UXJbMp0CTz7XGGeMio1xKFb+aM6MN2m+R6A5Mm IiHb3NojZWmw34F9acl2roPSFKIkccfSbVJ89L4pNuxr3hNAZprR0PumltCJyJhj3putmJmUZE0yg qNBXynSDsxlw2DXKD1+42A==; 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 1q7a6D-0004tg-C3; Fri, 09 Jun 2023 07:16:23 -0400 Date: Fri, 09 Jun 2023 14:16:17 +0300 Message-Id: <83o7lo28e6.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Al Petrofsky on Thu, 8 Jun 2023 17:32:56 -0400) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Al Petrofsky > Date: Thu, 8 Jun 2023 17:32:56 -0400 > > While the minibuffer window is active, attempt to switch buffers in > an ordinary window like so: > > emacs -Q > M-: (setq enable-recursive-minibuffers t) RET > M-x C-x o C-x b foo RET > > In emacs 27 and earlier, that will switch the buffer in the main > window to the new buffer named "foo", but in emacs 28.2, it generates > a bogus "user-error: Cannot switch buffers in minibuffer window". Seems like read-buffer-to-switch (called by "C-x b") changes the selected-window: when it returns, the rest of the function runs with the minibuffer window being the selected-window, which is wrong in this case. I couldn't find the offending change, but I doubt that bisection would help us in this case, given how many water went under the bridge of using the minibuffer and saving/restoring the window configuration. The ugly kludge below seems to fix the problem. Stefan and Martin, any better ideas or hints? diff --git a/lisp/window.el b/lisp/window.el index a11b1a5..6777944 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -8941,7 +8941,9 @@ switch-to-buffer "Cannot switch buffers in a dedicated window"))) ('pop nil) (_ (set-window-dedicated-p nil nil) 'force-same-window))))))) - (list (read-buffer-to-switch "Switch to buffer: ") nil force-same-window))) + (save-selected-window + (list + (read-buffer-to-switch "Switch to buffer: ") nil force-same-window)))) (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)) (set-window-start-and-point (not switch-to-buffer-obey-display-actions))) (cond From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 15:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Al Petrofsky , martin rudalics , 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168632333718906 (code B ref 63967); Fri, 09 Jun 2023 15:09:01 +0000 Received: (at 63967) by debbugs.gnu.org; 9 Jun 2023 15:08:57 +0000 Received: from localhost ([127.0.0.1]:60087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7djV-0004us-9J for submit@debbugs.gnu.org; Fri, 09 Jun 2023 11:08:57 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7djU-0004uf-Eo for 63967@debbugs.gnu.org; Fri, 09 Jun 2023 11:08:56 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DF2694428F0; Fri, 9 Jun 2023 11:08:50 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3DC0A4428EE; Fri, 9 Jun 2023 11:08:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686323325; bh=8hAHnnLP9Oc3YaS3wXUJTSSxdSuzeqYo9Pr7flLQolE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZLdsaJ6KPddOVro6ywT5QDXu++7E/pRtCzAuiJ4j/rhk4BFxnuUt2dFzYyO5k8d/Y xKSZzodyGzbyIyardE0Vkhp0uKjzWlpLXMMxW/SeP4LwgaSdKXSp+S08F4qyNGrF2t rzL5W29qcC6ni05JLrTb85qn5z5H5GGhdrn8qXvLLvb4AqlCmnJfkpDQb6E5Kf5iEr zpwaISicv95Y0x/etX9cn2Ys1wVbQmwUlUFsmBqLA/zpn+SnCBX7G6IINdrrM+licj yUNR3hNSLohJ4XyOUUHFx7nKcCE7O/k2N0aoOTxWJ5Jmgbd+27bgSUgMSMn14hpIZ+ RliGYMRPHJijA== Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 171E5120903; Fri, 9 Jun 2023 11:08:45 -0400 (EDT) From: Stefan Monnier In-Reply-To: <83o7lo28e6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Jun 2023 14:16:17 +0300") Message-ID: References: <83o7lo28e6.fsf@gnu.org> Date: Fri, 09 Jun 2023 11:08:43 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.012 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Seems like read-buffer-to-switch (called by "C-x b") changes the > selected-window: when it returns, the rest of the function runs with > the minibuffer window being the selected-window, which is wrong in > this case. Are you 100% sure that's what happens? AFAICT `read-buffer-to-switch` uses the minibuffer in the normal way so when we exit the minibuffer the selected window should definitely not still be the mini-window. And if it happens with `read-buffer-to-switch` I can't see any reason why it wouldn't happen for most/all other uses of the minibuffer. Stefan From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 16:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: al@petrofsky.org, rudalics@gmx.at, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16863269612463 (code B ref 63967); Fri, 09 Jun 2023 16:10:02 +0000 Received: (at 63967) by debbugs.gnu.org; 9 Jun 2023 16:09:21 +0000 Received: from localhost ([127.0.0.1]:60204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7efw-0000df-M7 for submit@debbugs.gnu.org; Fri, 09 Jun 2023 12:09:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7efu-0000dS-Nw for 63967@debbugs.gnu.org; Fri, 09 Jun 2023 12:09:19 -0400 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 1q7efo-00089T-DW; Fri, 09 Jun 2023 12:09:12 -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=Rzkg4Z3srV6KMqNRp3WhL2GLG6vn44mkNR6pe0yxYvE=; b=qBwGECiHqi2D A75ViVLFLv5UF+Pl1X4yw2UhCSzqYKv/rmLDz/s/UOQBRWiQINs8zD2CDjjrskPNnSSLJ4sQqeoAA nkjuSQOfogcWrs2a7nrk7YunNFoQZpd/R4pvWg9xiIoHjV8CPdqlIo2kf292DI+xX0/qXAgf+J1r0 47gbA16KrhOvImR1VeaTMhaMRGSLLbxNhcOE8GC9W6DOrIx1heYoExdeaouyA9OcQ/7YEv97SEViA RRbWReuJXQtpI1Q/i7HXn7/SeR+k5M2DxLJ3KjRsp7DvIio4rkESENCxbVT1R5QGdN0F1t9Gk2wk9 1OIUmE+H5rZlMbauCqDBzw==; 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 1q7efn-0001LA-UA; Fri, 09 Jun 2023 12:09:12 -0400 Date: Fri, 09 Jun 2023 19:09:19 +0300 Message-Id: <83fs701uts.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 09 Jun 2023 11:08:43 -0400) References: <83o7lo28e6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Al Petrofsky , martin rudalics , > 63967@debbugs.gnu.org > Date: Fri, 09 Jun 2023 11:08:43 -0400 > > > Seems like read-buffer-to-switch (called by "C-x b") changes the > > selected-window: when it returns, the rest of the function runs with > > the minibuffer window being the selected-window, which is wrong in > > this case. > > Are you 100% sure that's what happens? Yes, I'm sure. First, the window-minibuffer-p call in the interactive form: (interactive (let ((force-same-window (unless switch-to-buffer-obey-display-actions (cond ((window-minibuffer-p) nil) <<<<<<<<<<<<<<<<<<<<<<<<<<<< ((not (eq (window-dedicated-p) t)) 'force-same-window) ((pcase switch-to-buffer-in-dedicated-window ('nil (user-error "Cannot switch buffers in a dedicated window")) ('prompt (if (y-or-n-p (format "Window is dedicated to %s; undedicate it?" (window-buffer))) (progn (set-window-dedicated-p nil nil) 'force-same-window) (user-error "Cannot switch buffers in a dedicated window"))) ('pop nil) (_ (set-window-dedicated-p nil nil) 'force-same-window))))))) (list (read-buffer-to-switch "Switch to buffer: ") nil force-same-window))) returns nil, as expected (since this runs in the window to which we changed with "C-x p", before Emacs prompts for the buffer to switch to). But then the call to window-minibuffer-p in the body of the function: (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)) (set-window-start-and-point (not switch-to-buffer-obey-display-actions))) (cond ;; Don't call set-window-buffer if it's not needed since it ;; might signal an error (e.g. if the window is dedicated). ((and (eq buffer (window-buffer)) ;; pop-to-buffer-same-window might decide to display ;; the same buffer in another window (not switch-to-buffer-obey-display-actions))) ((and (window-minibuffer-p) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (not switch-to-buffer-obey-display-actions)) (if force-same-window (user-error "Cannot switch buffers in minibuffer window") (pop-to-buffer buffer norecord))) returns non-nil, although we were supposed to be out of the minibuffer by that time. I've verified that selected-window returns the original non-minibuffer window in the first place and the minibuffer window in the second. I then ran the recipe under GDB, with a watchpoint on selected_window, and clearly saw that it stays at its mini-window value by the time we exit read-buffer-to-switch. > And if it happens with `read-buffer-to-switch` I can't see any reason > why it wouldn't happen for most/all other uses of the minibuffer. It probably does, yes. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 16:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Al Petrofsky , martin rudalics , Stefan Monnier , 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16863295686948 (code B ref 63967); Fri, 09 Jun 2023 16:53:02 +0000 Received: (at 63967) by debbugs.gnu.org; 9 Jun 2023 16:52:48 +0000 Received: from localhost ([127.0.0.1]:60259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7fM0-0001o0-0e for submit@debbugs.gnu.org; Fri, 09 Jun 2023 12:52:48 -0400 Received: from heytings.org ([95.142.160.155]:37522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7fLy-0001np-Co for 63967@debbugs.gnu.org; Fri, 09 Jun 2023 12:52:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1686329564; bh=nFuyGcB/LHPaZ5a/vHCAABADejhQJE7DcL3uyp52Hy8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=Rn1V0nUnFRUW6lNUQYzJt8NwzGJz9YQXx4U0zRuY2W29Fkz9C9L6pCvk/b/sBh+Yi w3mZfsOzRrIYOSiPpd4NrHwiaWS6mm0jogfT/JljL90ompC0UN3Og5ncZhF6f2xcY7 VCLzrabGz6ikxD78Kgn9Tjl3RrLWGr0cWmFB39TpHxLcuyNZyDbUY+yT8IkO+zZdvG tWRxGVkbCQyhg/PPc3kayIzzjhjIEDWECoLqZ4ULv3MDB7i55nWcPjG8iQrkgLML1X loJgvXCJCkutLDQkNrRIsv/gnFr8SX/vtIfwJX4GU6kZthKIsiVgKHfw9QgdbDK/MQ DKtnpZ/A4MQvg== Date: Fri, 09 Jun 2023 16:52:44 +0000 From: Gregory Heytings In-Reply-To: <83o7lo28e6.fsf@gnu.org> Message-ID: References: <83o7lo28e6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > I couldn't find the offending change > It's 7c2ebf6e23. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 17:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gregory Heytings Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16863313129961 (code B ref 63967); Fri, 09 Jun 2023 17:22:01 +0000 Received: (at 63967) by debbugs.gnu.org; 9 Jun 2023 17:21:52 +0000 Received: from localhost ([127.0.0.1]:60279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7fo8-0002ab-Ci for submit@debbugs.gnu.org; Fri, 09 Jun 2023 13:21:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57064) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7fo5-0002aL-Lc for 63967@debbugs.gnu.org; Fri, 09 Jun 2023 13:21:50 -0400 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 1q7fnx-0004OW-Qi; Fri, 09 Jun 2023 13:21:41 -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=QU4l0SD3cHUhZoIPQHsXD3nBlnWXU8AIIdkMLe2nCao=; b=TQ1kNdaw0MHp blM7dF0x6AJMnOCoPnFsZ5074xZhKIg9jxMGweV4Iw+LhhGufOhHJXvHmYP98BSllWXw3w4hWW+5J QBkPdkbcZ8J5XNdU9BHg6nisBtNOn0ny14c+sOrp2cCxJeoKQglBSHoFN7Fk2CdktkrbvYCc1lcAd abhIbqvOgiU6V3BE32uuMdSVGoh2EOKRA1RnYdorUhzJrQOxSFHK6jvO7k+L3hUX5ZuD3k+6r3TuU 4dSaJyQC/rln2/WVnpfKHTtFV11d+ZtJ7Zoc+83qDinv9FNTMNUyoFdbYkTSx/HOkqW90COvR1rbO ybjGSv3f39XLAlN21QrwHg==; 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 1q7fnx-0000DL-8Z; Fri, 09 Jun 2023 13:21:41 -0400 Date: Fri, 09 Jun 2023 20:21:49 +0300 Message-Id: <83cz241rgy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gregory Heytings on Fri, 09 Jun 2023 16:52:44 +0000) References: <83o7lo28e6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 09 Jun 2023 16:52:44 +0000 > From: Gregory Heytings > cc: Al Petrofsky , martin rudalics , > Stefan Monnier , 63967@debbugs.gnu.org > > > I couldn't find the offending change > > It's 7c2ebf6e23. Thanks. Yes, I imagined it would be it. Which is why I said: it won't help us to know which commit changed that. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 19:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Alan Mackenzie Cc: al@petrofsky.org, rudalics@gmx.at, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168633831121491 (code B ref 63967); Fri, 09 Jun 2023 19:19:02 +0000 Received: (at 63967) by debbugs.gnu.org; 9 Jun 2023 19:18:31 +0000 Received: from localhost ([127.0.0.1]:60359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7hd1-0005aZ-0Z for submit@debbugs.gnu.org; Fri, 09 Jun 2023 15:18:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7hcy-0005aJ-57 for 63967@debbugs.gnu.org; Fri, 09 Jun 2023 15:18:29 -0400 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 1q7hcr-0001US-2I; Fri, 09 Jun 2023 15:18:21 -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=W/ycByNmkZjva10/+wR4nrifJsZn2M4BI1AudA9wQYg=; b=dTvj3L22ewJ6 T46rLlg2nryR7YSIy4hQC9XH4mqhn/GQhVookg1nBKCs7jwkx7F4n/A5ROFxKP3kCKACzxuzOPUfY lmZ8HWMk+H7i0kQYTmvCt+8oFKbokdCFOCYbSVNvEsIpZAAtwoLL0nBqyEn4fMfqSZ1yc7Yev4saO 0YCypCx1IVQdgCGQyzwuanDwTP7RlSRDX8k+kUTfEqaWcxHC476/ARBfCOSYxc6jggnaiUaPsSFTu t1Qwc3BV9JuJd4tWAG5mX1CcfG12rTcuM6tJLztV5VnOkW9z6y+hi3WoeCA8wHkWg0JnK/u7JBvaw sCPGUrCa85uMfj34cHHSWw==; 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 1q7hcd-0006kW-7b; Fri, 09 Jun 2023 15:18:20 -0400 Date: Fri, 09 Jun 2023 22:18:08 +0300 Message-Id: <83a5x81m33.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83fs701uts.fsf@gnu.org> (message from Eli Zaretskii on Fri, 09 Jun 2023 19:09:19 +0300) References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: al@petrofsky.org, rudalics@gmx.at, 63967@debbugs.gnu.org > Date: Fri, 09 Jun 2023 19:09:19 +0300 > From: Eli Zaretskii > > > And if it happens with `read-buffer-to-switch` I can't see any reason > > why it wouldn't happen for most/all other uses of the minibuffer. > > It probably does, yes. AFAICT, the clobbering of the selected window happens in minibuffer_unwind: static void minibuffer_unwind (void) { struct frame *f; struct window *w; Lisp_Object window; Lisp_Object entry; if (NILP (exp_MB_frame)) return; /* "Can't happen." */ f = XFRAME (exp_MB_frame); window = f->minibuffer_window; w = XWINDOW (window); if (FRAME_LIVE_P (f)) { /* minibuf_window = sf->minibuffer_window; */ if (!NILP (w->prev_buffers)) { entry = Fcar (w->prev_buffers); w->prev_buffers = Fcdr (w->prev_buffers); set_window_buffer (window, Fcar (entry), 0, 0); Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); /* set-window-configuration may/will have unselected the mini-window as the selected window. Restore it. */ Fset_frame_selected_window (exp_MB_frame, window, Qnil); <<<<<<<<< } else set_window_buffer (window, nth_minibuffer (0), 0, 0); } } And since minibuffer_unwind is called _after_ restore_window_configuration, it overwrites what the latter does. Why minibuffer_unwind doesn't test some condition which would tell it at all has to do something, I don't know. It seems to think that the frame exp_MB_frame is still live and that its "expired" minibuffer needs to be replaced? why? Is the logic inside read_minibuf_unwind flawed in the case that enable_recursive_minibuffers is non-zero? From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 20:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168634108626482 (code B ref 63967); Fri, 09 Jun 2023 20:05:02 +0000 Received: (at 63967) by debbugs.gnu.org; 9 Jun 2023 20:04:46 +0000 Received: from localhost ([127.0.0.1]:60759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7iLl-0006t0-Dk for submit@debbugs.gnu.org; Fri, 09 Jun 2023 16:04:46 -0400 Received: from heytings.org ([95.142.160.155]:37712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7iLj-0006sn-GD for 63967@debbugs.gnu.org; Fri, 09 Jun 2023 16:04:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1686341082; bh=NDYCi0dOB3JIHHTu1OrgkAFCjnKAJZirZplzwB21H1I=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=iTG1HkCMorFUF3XFhGvVqxyLVxOjG8CquvKJalPzMjusXopwHbfLmXj2kZ1bMVLlX ZRtxeKt6TyzIYZPfxK63E6zZzngTzgGFVWUFR3+TCm/e4W0Lnwddt2KhMC4bG+af5M HPcAa08wrcXKU9S0cIS7Yb8UNEEmIRw5xUssT7bZKZmLLUyWqHc+DWhRlp13d7142m CCQ1MTUI8sdi5OB27LRRTsquFx8oCmJu5ho22nVi3ZRM1qM1hjdGl7gbO2lCDbLd4c yEJuEq1Hm+pY+9UNXI27pMl7/6EYo7dt9qEfZHfyejhQ89o4LAmt6GaxoLwJXaLgBh /X0/Idq67RU6w== Date: Fri, 09 Jun 2023 20:04:42 +0000 From: Gregory Heytings In-Reply-To: <83cz241rgy.fsf@gnu.org> Message-ID: References: <83o7lo28e6.fsf@gnu.org> <83cz241rgy.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> I couldn't find the offending change >> >> It's 7c2ebf6e23. > > Thanks. Yes, I imagined it would be it. Which is why I said: it won't > help us to know which commit changed that. > Given your last post, apparently it did help ;-) From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 06:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gregory Heytings Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168637676322363 (code B ref 63967); Sat, 10 Jun 2023 06:00:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 05:59:23 +0000 Received: from localhost ([127.0.0.1]:33092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7rdD-0005od-6p for submit@debbugs.gnu.org; Sat, 10 Jun 2023 01:59:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7rd9-0005oO-Nd for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 01:59:21 -0400 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 1q7rd3-0005Bp-Eb; Sat, 10 Jun 2023 01:59:13 -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=LcYFy7bfIu0gE1oPuAXUUYzrP7oSGpbM95RPRgrN7Ro=; b=cbDNL7JYeyRr vg6dfEytqaazyy1wsokE+ambyK6UNWIZyD0OXRRSZ7JsWb+ndKkRtxNxeJC2Uao+j/9Y+gcdpgKxZ rCZMo1MwNA5DFI7AvVJbUlO9hWyWwhGXJAnDCpu4V9NvWGwD5LTxDlebWS8QbRyBUn4IcOxI/fduF J+M4O9I56l9OS3TAnMLnqDaNFZZbs+STpeUAiOd9b2CXasCPnaGqjA2E4zZ1cmpCzWp+G3MZUv33b YDOBKNQWrbU/+l1pDTIWWExliZKnZ8uBJ6nRgt8npbGvKP9MVIK0Ura1QH4xPQMftk4dyU5PPeAUl I5UkkFVG9Yo0ReF05dtwnQ==; 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 1q7rd2-0001Q0-U7; Sat, 10 Jun 2023 01:59:13 -0400 Date: Sat, 10 Jun 2023 08:59:23 +0300 Message-Id: <835y7v26ys.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gregory Heytings on Fri, 09 Jun 2023 20:04:42 +0000) References: <83o7lo28e6.fsf@gnu.org> <83cz241rgy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 09 Jun 2023 20:04:42 +0000 > From: Gregory Heytings > cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > 63967@debbugs.gnu.org > > > >>> I couldn't find the offending change > >> > >> It's 7c2ebf6e23. > > > > Thanks. Yes, I imagined it would be it. Which is why I said: it won't > > help us to know which commit changed that. > > > > Given your last post, apparently it did help ;-) Unfortunately, no, because the changeset is huge, and just knowing what part of it could cause this is a non-trivial job. Fortunately, the code which clobbers the selected-window was clearly visible in GDB, which is what led to my previous post. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 06:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168637918526704 (code B ref 63967); Sat, 10 Jun 2023 06:40:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 06:39:45 +0000 Received: from localhost ([127.0.0.1]:33112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7sGH-0006we-9B for submit@debbugs.gnu.org; Sat, 10 Jun 2023 02:39:45 -0400 Received: from heytings.org ([95.142.160.155]:38224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7sGF-0006wU-7c for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 02:39:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1686379182; bh=ZRmMJo3NLjMibExaPaOrQUtoENcCNzixQCssgSZ9IzE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=c5w8N5Pw48lMX8JJAp1lruCwHvMmKIc0Z/ncDe54lSZSqy+5c8ezr5aZyvDI9yMfF ryljk2r2164gP9AaEejGGAwSPN2Lk+RFwZ/vDKkDXKOkMwzk8tKBIiqzvOyx7ADEbM 0U1NIyoyC3UmvprGvl0Hv7R7ivZ5ebT58/7S2nb/pgHOlnohQnyqL+HxUzamYweCeB E05bPPJmbf5T6p8rUHNuzK4QStVl+1HthK4d6/VHB4moQlJfAu603OU++ThFVE9ckZ zRGvzW3uez0Kj2VCwriGkBEyX525lJ06SA17LJFUObawA34tq3qrD/ZzdVBHbrDjMD ZOBX5fvS+41HQ== Date: Sat, 10 Jun 2023 06:39:41 +0000 From: Gregory Heytings In-Reply-To: <835y7v26ys.fsf@gnu.org> Message-ID: <3c82fb01f4aa90537660@heytings.org> References: <83o7lo28e6.fsf@gnu.org> <83cz241rgy.fsf@gnu.org> <835y7v26ys.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> I couldn't find the offending change >>>> >>>> It's 7c2ebf6e23. >>> >>> Thanks. Yes, I imagined it would be it. Which is why I said: it >>> won't help us to know which commit changed that. >> >> Given your last post, apparently it did help ;-) > > Unfortunately, no, because the changeset is huge, and just knowing what > part of it could cause this is a non-trivial job. Fortunately, the code > which clobbers the selected-window was clearly visible in GDB, which is > what led to my previous post. > I see. Apparently we don't work the same way. I didn't have time to investigate this issue further after bisecting, but the first thing I would have done is to determine which of the four calls to Fset_frame_selected_window in that changeset is responsible for that bug. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 06:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gregory Heytings Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168637951227298 (code B ref 63967); Sat, 10 Jun 2023 06:46:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 06:45:12 +0000 Received: from localhost ([127.0.0.1]:33117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7sLY-00076E-0h for submit@debbugs.gnu.org; Sat, 10 Jun 2023 02:45:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7sLV-00075w-C4 for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 02:45:10 -0400 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 1q7sLO-0003rU-8n; Sat, 10 Jun 2023 02:45:02 -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=1Ci22ALC4+zjxbTx61ZrJJEQQ5+CVcfotTxK9HfejOs=; b=LTMdmpRdi9Ng Vyx1nfaHBeFsOj2ROpBG4gGXuPYKAKr6uTtk4lVgkTgABv5Jl9RV4FsrMS3iOO/8eKzyOaIergvYQ sfA5Yxa1i1uCs+/RJbbkWYPj+XPU3/JLTO0p4aFBAVYoS8zrWOmMiFWdj1XOaL5iWNVByKdBXf+/K 2l32PBceqerVGx0C/1KjwKxFHxk3kv+a6T77oVJDdNuoilcjPDZ1uEeoirHVtQmQuNOcM5isvuX1H 8UPp78CM7SUnq5p77cV0ArUec7lj6H8Ea0CwHnOthT1/ijYKCVtjv6XddGEkV0D662JVatVwftBfs 6daUhPIQezE+IaI7hVPXAQ==; 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 1q7sLN-0004NG-2H; Sat, 10 Jun 2023 02:45:01 -0400 Date: Sat, 10 Jun 2023 09:45:11 +0300 Message-Id: <83352z24ug.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <3c82fb01f4aa90537660@heytings.org> (message from Gregory Heytings on Sat, 10 Jun 2023 06:39:41 +0000) References: <83o7lo28e6.fsf@gnu.org> <83cz241rgy.fsf@gnu.org> <835y7v26ys.fsf@gnu.org> <3c82fb01f4aa90537660@heytings.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 10 Jun 2023 06:39:41 +0000 > From: Gregory Heytings > cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > 63967@debbugs.gnu.org > > I see. Apparently we don't work the same way. I didn't have time to > investigate this issue further after bisecting, but the first thing I > would have done is to determine which of the four calls to > Fset_frame_selected_window in that changeset is responsible for that bug. You assume that the only way to change the selected-window on the C level is by calling Fset_frame_selected_window? That's false; just try grepping the C sources for "selected_window =". And that's even before you consider the possibilities of indirect setting, when the actual setting is in Lisp via some proxy. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 06:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Al Petrofsky , Stefan Monnier Cc: 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168637999128482 (code B ref 63967); Sat, 10 Jun 2023 06:54:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 06:53:11 +0000 Received: from localhost ([127.0.0.1]:33145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7sTH-0007PI-BE for submit@debbugs.gnu.org; Sat, 10 Jun 2023 02:53:11 -0400 Received: from mout.gmx.net ([212.227.15.15]:54625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7sTE-0007P5-LM for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 02:53:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1686379979; x=1686984779; i=rudalics@gmx.at; bh=pGX174wRS1nYVBhaHIapiopbFMzgVVWJcdBJ7dWW+w8=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=ud6omFdVBVq7VVpWCs9a3pYd93Ba/LpN4RmAdwvaDGk1iA87Vxg1duh0emb6PQdsangoewK J2BzheITBluasNIrj+B5T9E0AcjfAPPKRDAMY1KBMTTHoSHZm5HFMGKqk4c6gV4gmQR2HOhT1 9CExGhRVy5WtNPvimvHnmJzhIK5cmLpl2DDzpOpdVEHIMEplm0iCZe80TGjPFuKNarNMF2bxT 7m/LGJZhAe8cnImCoQBFLeWjHCJ+Eth3lqrazUYpJQbFsFAXOALnN6QFAz/f+XAmD07nO8tk+ R12m30WmM7qYLx374cOEFEKXEoxtjXCSWtkd/9G0yLj33daWf8HQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([212.95.5.146]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKsjH-1qQuDn3zMT-00LFPp; Sat, 10 Jun 2023 08:52:59 +0200 Message-ID: <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> Date: Sat, 10 Jun 2023 08:52:57 +0200 MIME-Version: 1.0 Content-Language: en-US References: <83o7lo28e6.fsf@gnu.org> From: martin rudalics In-Reply-To: <83o7lo28e6.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:gWRGjn+Utc3CQwIkcqLAtKcHfLno9skaEJC35nTgTWuLUIlKZcP LHDiX6otqHvcYryj3D4/DFI+BOUdN3Yu1FsFCucmlBFMxmITZkCgmnO7ltekMQbpEDbg+/n mg+02TUfUhI8mia+BYAOgZivVtS98dqZ7d6FCauFXtUzCtTRk8soaGwM4fEmBTCnf9CpTk9 7SjcaLppem7BRrZveEW4Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:64foIftWxew=;p7S87+zdUexnXVYfDsDCeTmX4hB aIQgY3D4bGICXwsDlF8andm+8B54R2VkDzhpzBKTV/ZVfhHHKIu/bKpj3sfXP2r8c8sDK0u6S JkygUSDYrODCSQkxNJJ97zUEAXQ9I6YAdYTZNHRdWY0OYD8boczFfiWeCHdDeGzk6ziux2Yg7 WTWBORR4TrvxAxH9bWVfTjK1GParEYPMbYIF8ulS4tCYKU7XjsniFBVRPtRbeug8jyZaH2yOu VjhZ526lmiwLSSsTDSJkr3Hs7d7SOmsteidU8B2z9PfWVTz8HIyp4Ax/mJzO7xZawFrPRiFH5 DpcvUS9bDt1jC7TBe1yUGZ2MNGZLetFeQWbVGaPElPsrFskPumsMNFssEguonaE74fm8MTNel 3Mty9MJC4tRa+bkbLu3gi0iidCgf62cOSs06UXAa5B+qNWOp7aAqnAG7lb5P2gWjYkcqJdk3V 7FywLrJTMoprIeoodK/j0IzDrrNJsX8jqee/PAJsnKSY6y7NoFusQtIeC6tqhQIfCTCdTHum8 cc7dguMp/9rB4poxl6nHk3JcJw8XClDyczM8ESk/VzdBKnFvTfgwWskvtZUXKhGNqRMoxBI23 0ReEgT4X1HcfCLHsDonv34Rc2mlXHNcxUgpCh3rgIt9FXvB9j6Fk2R4ASbv8NvdKOCGHA4gwm 09URQseZdErtvVB6VFM5lztlSApwjQ4QN8iqGG1KZW7+0XM3ONIgevGV//MXUooZLtqRy9ejs Ytwg6/AkQjXBACRNsyI8ZtygV7NZMO0f9v4BZxrOS/QKii92UxTp07drBtupadbWyI3713kDo UTi21a7HFYazbGgZYk24EU46iDxPQKlirwlIHuVj4FvAf0u3uZLbEdn1vdUQ5hCsnaIcUQD3X eu4BSKMMXQo5fVGOjKD+JMGIZuA+U6vJptoIOsXJOGHHzZ4CmQSG64eaK5kOiWJ1VRvWmfhII RySmWNq1DrIFFBnX6Cc0JCQZu9A= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > diff --git a/lisp/window.el b/lisp/window.el > index a11b1a5..6777944 100644 > --- a/lisp/window.el > +++ b/lisp/window.el > @@ -8941,7 +8941,9 @@ switch-to-buffer > "Cannot switch buffers in a dedicated window"))) > ('pop nil) > (_ (set-window-dedicated-p nil nil) 'force-same-window))))))) > - (list (read-buffer-to-switch "Switch to buffer: ") nil force-same-window))) > + (save-selected-window > + (list > + (read-buffer-to-switch "Switch to buffer: ") nil force-same-window)))) > (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)) > (set-window-start-and-point (not switch-to-buffer-obey-display-actions))) > (cond That wouldn't help in all other use cases of read_minibuf where the user will be thrown back to the minibuffer window as well. I'd rather try (the still timid) -static void minibuffer_unwind (void); +static void minibuffer_unwind (Lisp_Object); ... - record_unwind_protect_void (minibuffer_unwind); + record_unwind_protect (minibuffer_unwind, selected_window); ... -minibuffer_unwind (void) +minibuffer_unwind (Lisp_Object old_selected_window) ... + if (!EQ (old_selected_window, FRAME_SELECTED_WINDOW (f))) + Fset_frame_selected_window (exp_MB_frame, window, Qnil); since the last line seems to suggest that exp_MB_frame should not be the selected frame. martin From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 08:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16863857086225 (code B ref 63967); Sat, 10 Jun 2023 08:29:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 08:28:28 +0000 Received: from localhost ([127.0.0.1]:33209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7txT-0001cL-N5 for submit@debbugs.gnu.org; Sat, 10 Jun 2023 04:28:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7txS-0001c8-Hn for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 04:28:27 -0400 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 1q7txM-0002gj-UB; Sat, 10 Jun 2023 04:28:20 -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=piC76RvRujKduoqnQVJVRzRxPhaXJapjKjrKf10Eplw=; b=HtAO9sKTsDv1 +cwaGVDxus7o/isU4lJ2/lSTwFMXoymGf11kRJ+7vMG2mD2UPHqU+S3yHalk1w/i/whhSMUw9P6m2 33m8f+L0yasIFTEzjfd+Wq6k+ThYMS/O56uEtOTqpe//gy/tAkgYhHAS3Z4eS5QxYc4HCbezZ/lQ5 tmi+nQGj9bmsv2O0FOZN7gVHuXr8DU5hnxj0uNwsXa0PcVLzyqz1EWPa9VR+RnhqV/JeApBnBGi8F o/mFLAi1W7EvVuO1L3N3DJL+dQI8E7wRwh4AVxmyVoSiaj6Xn6csARfJ0aqCP+Japj9FczdETQSNJ Frpu0bbb+RH77lUrRxw2Ig==; 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 1q7txM-00056U-1i; Sat, 10 Jun 2023 04:28:20 -0400 Date: Sat, 10 Jun 2023 11:28:29 +0300 Message-Id: <83y1krzpoy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> (message from martin rudalics on Sat, 10 Jun 2023 08:52:57 +0200) References: <83o7lo28e6.fsf@gnu.org> <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 10 Jun 2023 08:52:57 +0200 > Cc: 63967@debbugs.gnu.org > From: martin rudalics > > > diff --git a/lisp/window.el b/lisp/window.el > > index a11b1a5..6777944 100644 > > --- a/lisp/window.el > > +++ b/lisp/window.el > > @@ -8941,7 +8941,9 @@ switch-to-buffer > > "Cannot switch buffers in a dedicated window"))) > > ('pop nil) > > (_ (set-window-dedicated-p nil nil) 'force-same-window))))))) > > - (list (read-buffer-to-switch "Switch to buffer: ") nil force-same-window))) > > + (save-selected-window > > + (list > > + (read-buffer-to-switch "Switch to buffer: ") nil force-same-window)))) > > (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)) > > (set-window-start-and-point (not switch-to-buffer-obey-display-actions))) > > (cond > > That wouldn't help in all other use cases of read_minibuf where the user > will be thrown back to the minibuffer window as well. I'd rather try (the > still timid) > > -static void minibuffer_unwind (void); > +static void minibuffer_unwind (Lisp_Object); > ... > - record_unwind_protect_void (minibuffer_unwind); > + record_unwind_protect (minibuffer_unwind, selected_window); > ... > -minibuffer_unwind (void) > +minibuffer_unwind (Lisp_Object old_selected_window) > ... > + if (!EQ (old_selected_window, FRAME_SELECTED_WINDOW (f))) > + Fset_frame_selected_window (exp_MB_frame, window, Qnil); > > since the last line seems to suggest that exp_MB_frame should not be the > selected frame. That works, but does it make sens to do the other stuff in that if clause in that case? We do: if (!NILP (w->prev_buffers)) { entry = Fcar (w->prev_buffers); w->prev_buffers = Fcdr (w->prev_buffers); set_window_buffer (window, Fcar (entry), 0, 0); Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); /* set-window-configuration may/will have unselected the mini-window as the selected window. Restore it. */ if (!EQ (orig_selected_window, FRAME_SELECTED_WINDOW (f))) Fset_frame_selected_window (exp_MB_frame, window, Qnil); } Does it make sense to manipulate the buffer, window-start, and window-point of WINDOW if we are not going to make it the selected window? In general, I don't think I understand the logic of this function at all. Since this is about the "expired minibuffer", then the code seems to assume that when a minibuffer is "expired", and there are previous minibuffers for that mini-window, the mini-window stays the selected-window? But that is not true when recursive minibuffers are enabled, right? IOW, I wonder whether your suggested change just postpones the problem by moving it to the rarer cases when more than one frame is involved in this dance. Why is it okay to set the selected-window of another frame here? From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 08:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16863867458058 (code B ref 63967); Sat, 10 Jun 2023 08:46:01 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 08:45:45 +0000 Received: from localhost ([127.0.0.1]:33242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7uEC-00025u-Mu for submit@debbugs.gnu.org; Sat, 10 Jun 2023 04:45:45 -0400 Received: from heytings.org ([95.142.160.155]:38340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7uE9-00025l-S1 for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 04:45:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1686386740; bh=wSVI/HKVSstCS7jRCGTwMTd3eDQ+L5zIsJFkvgaw3iM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=wxImpdZS7Zmkk9QZE8vB9PkinuuoLQZiCieMEvZBbCcHj1P+aiAdB/oUkUwoyJ3Q9 N2onSk8PCDLzOR4lf4c+hoak0lTBSycn5/c/qByet52YxH8I7p1pMAOfRH9boqdc0c RoWPJmpLKr1WSNXkP1MUgCActblRaNT8dpVSEsiZEbAdX0aqhufAIgiPqnmR1ZM2S0 +Lewm6XhLq0h4SyG4QBws/3RbTUIaIq1tgGMscONx3w1/nmXSiqvUXRoxt5fv4r1q0 oNxqx7SPgBo5Fy99Lh0tsgVrQPMvqmB+9pFAKn/kZWbdvKVlcjvBG+s6Ay1wp42k6Y nxZKaFSet4uDA== Date: Sat, 10 Jun 2023 08:45:40 +0000 From: Gregory Heytings In-Reply-To: <83352z24ug.fsf@gnu.org> Message-ID: <3c82fb01f4e9db2eeaf9@heytings.org> References: <83o7lo28e6.fsf@gnu.org> <83cz241rgy.fsf@gnu.org> <835y7v26ys.fsf@gnu.org> <3c82fb01f4aa90537660@heytings.org> <83352z24ug.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> I see. Apparently we don't work the same way. I didn't have time to >> investigate this issue further after bisecting, but the first thing I >> would have done is to determine which of the four calls to >> Fset_frame_selected_window in that changeset is responsible for that >> bug. > > You assume that the only way to change the selected-window on the C > level is by calling Fset_frame_selected_window? That's false; just try > grepping the C sources for "selected_window =". And that's even before > you consider the possibilities of indirect setting, when the actual > setting is in Lisp via some proxy. > I don't think it's useful to argue, I'm just observing that we don't work the same way. But no, I don't assume anything, on the contrary. Just commenting out each one of the Fset_frame_selected_window in that changeset in turn, and checking whether doing that fixes the bug, shows that the culprit is the call to Fset_frame_selected_window in minibuffer_unwind. Doing that does not involve any guesswork, and the result is 100% accurate. Of course, that's not the end of the story, and of course, it could have turned out that none of these four calls is the culprit (in which case I would probably have checked the five calls to set_window_buffer). From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168640873025823 (code B ref 63967); Sat, 10 Jun 2023 14:53:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 14:52:10 +0000 Received: from localhost ([127.0.0.1]:36101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7zwk-0006iO-4K for submit@debbugs.gnu.org; Sat, 10 Jun 2023 10:52:09 -0400 Received: from mout.gmx.net ([212.227.17.22]:54095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7zwe-0006hm-3c for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 10:52:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1686408710; x=1687013510; i=rudalics@gmx.at; bh=Mr6AHb3SgrOjwE/fvURt9CsqrcgtqhcDaE8rbG4N2Tw=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=oal3XZVueiaqfBdhgRZRBcAqgyJURyI7Dz6kROKYJ9roupW1wK/buhvcDOPD6KlPKBdPPmL B3ggqDNbzYvj3dCffmBiB5aZUZswsHFtHXmrqrAKzfb2drNMD3uIYDslH7NUCeiMGiB9IQW6x H44vPiom0+4QrZN2aaLGVwIk0/nnaGHzDPo7Yc3bnUF0x3H1Pcdb+f5JPc/I9dfteMmU2o541 /DguLcjdCzmVf+AOHbqy1y0ffP/83qPFxV81S1ie/JfpTpdQzj+m5GTKGCWU5yTmJaRYDX4u8 530mMdggo3A92Wo1eXV1+G4UMlbozkKj0MAqdjN7hSBIrs3JtLBw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([212.95.5.151]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MNKlu-1qWp1o0KOw-00OpGw; Sat, 10 Jun 2023 16:51:50 +0200 Message-ID: <8a540045-0f14-43cf-0515-4dcab2f68b98@gmx.at> Date: Sat, 10 Jun 2023 16:51:47 +0200 MIME-Version: 1.0 Content-Language: en-US References: <83o7lo28e6.fsf@gnu.org> <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> <83y1krzpoy.fsf@gnu.org> From: martin rudalics In-Reply-To: <83y1krzpoy.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PwH3tS/cmKon4G/I4v9y+6hJUHOHIVnH0uapdiMqRd82/7bvJ1w wE7xUxK1qavHz+7fC+OiDCn0Yt7Wrnm7cavcNf/kiZW2fvGFEjfjfWgj3Wxy2sRy7ApRBub 14Bl4x2cV1R7dQHxyt87suHiqL38R7E8Htp5e0m07hplrdTxvfWi8+rU0g+ZII9Xz36ywgE oIydbOeM8BqvmFx+8JkLQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:QasbAIWb/3E=;Y4qH2XPI3xeXPXDUKwT2xfqnmT7 4oZhZx6wi4avFZ5AcpkNAtScw41kWJtGD5dozvi02hs4VgeHjjzSNBGIYkH/XVl8C+k86Sglr QeH5KNMrnhMoJ2xGDN6Vh5fMMBHDc0FEq7kXM4Gw9zJXwzzwS2m2voPlhRCullgoMM6uWicfU sE1TXDJNVqAUcipxRRrKlgHjpNPSyL59fHp1zYx/dA85HJAQka58+0+mpOzzxuE3CU4bhK7na TetEjPkr1v4e1phe/FuHGBp7JJjCHfZkkPfQcypKrmklBHlaCS6pXr+1Jof4BHLavJo9oc15k 8oo7NHIVlK0ZKZFIy51SSLObsKWAp8yrJLcL0gZY3NrgiVN7qqHZ7VI1XiCsAt4GOYNy5xY55 /qH5JHvH0QROdQTGYEibD1AbosbOtnXr8kSicOo+Y4GNYIzfZwcTq4WF826mhEGdltuayQMBJ VxkBjpMpZ78ARQa7PlaHXPI2UCYJFrUfhIAQEd/eXyprwJ3us5ixio6DxGe50iXhvm1h8kJPz bW1bAI9OgHnnNx/eJqT9THbLEJz+FkzS/YKNublUpMzNK858hTFxeW0vNMspXJyy2oLvZpaMz z7wV6nKKHxKTEYSLnUIc/jOKgYoSNg48AFuGsXxcgaOSvSZMjyNZo4/Yu6bfapOuoAIEYVivA 9Ddm3EaBvmx3Az3NfT+zdVQkCA2W45dHDJWzCQUECBxygVF66X7+irW61VuO9/+hnIoRTiL3U /E/P4QQP4piOEci4UDda4RM0yZezNKI3HPNTdyBSyJxur3wwNVHZr2kRUvWse5vM/UZtepBcW ZsI4M1H+dFGJ3e2KsZIFQPhk0GZ9TiZI4sioNVEoKcMnO2t7dW06r7YaxOtkHMv/lX7dr5Iy+ zhB+JbBVIoyU3sU9Hgpy4vj6LJVyhy3DSK/w5vsQyGOUwJ1HhvL48Xf47tFzeVzd6MM1il51s grRGaSQ9gys8EcReV4Zp73TAp6Y= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > That works, but does it make sens to do the other stuff in that if > clause in that case? We do: > > if (!NILP (w->prev_buffers)) > { > entry = Fcar (w->prev_buffers); > w->prev_buffers = Fcdr (w->prev_buffers); > set_window_buffer (window, Fcar (entry), 0, 0); > Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); > Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); > /* set-window-configuration may/will have unselected the > mini-window as the selected window. Restore it. */ > if (!EQ (orig_selected_window, FRAME_SELECTED_WINDOW (f))) > Fset_frame_selected_window (exp_MB_frame, window, Qnil); > } > > Does it make sense to manipulate the buffer, window-start, and > window-point of WINDOW if we are not going to make it the selected > window? If w->prev_buffers gets us the right minibuffer to display here (any former dw->prev_buffers = sw->prev_buffers should guarantee that), then for that buffer we have to establish the corresponding start and point positions. This makes sense regardless of whether the minibuffer window will be selected or not. IIUC the present code either assumes that the user was in the minibuffer window before starting the last read_minibuf interaction or that Fset_frame_selected_window does not select the window when the frame is already selected. > In general, I don't think I understand the logic of this function at > all. Since this is about the "expired minibuffer", then the code > seems to assume that when a minibuffer is "expired", and there are > previous minibuffers for that mini-window, the mini-window stays the > selected-window? But that is not true when recursive minibuffers are > enabled, right? More precisely, it should not be true when a nested read_minibuf was invoked from a normal window as with C-x b, something that can happen only when `enable-recursive-minibuffers' is non-nil. This includes the simpler C-h f C-x o C-x b which means that a user does not have to enable them explicitly. > IOW, I wonder whether your suggested change just postpones the problem > by moving it to the rarer cases when more than one frame is involved > in this dance. Why is it okay to set the selected-window of another > frame here? I wouldn't know. That's why I called my proposal "timid". martin From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 15:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: al@petrofsky.org, rudalics@gmx.at, Eli Zaretskii , 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168641219931798 (code B ref 63967); Sat, 10 Jun 2023 15:50:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 15:49:59 +0000 Received: from localhost ([127.0.0.1]:36129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q80ql-0008Gl-22 for submit@debbugs.gnu.org; Sat, 10 Jun 2023 11:49:59 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q80qi-0008GV-9R for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 11:49:57 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E3073801D6; Sat, 10 Jun 2023 11:49:50 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 439D980443; Sat, 10 Jun 2023 11:49:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686412185; bh=B19BO6jDgDh2Cl1VRyxcuMCJAavHC3PbpVPTrsDFFTA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DMnZPzfH/T1nnkTAdCLmYC2a5Qv4o/sangP/znEW+C45JhrVzR5fDrBK3t5nLCtcu 5EKf6PghK4E/IYr385CbhExrfKlPHcbalU10MgPBExVoBu3hD7U5UowJ00hUK8ynL+ Qe5LGuNu1Jt7/q9mHjjWqmKkZXSAA58AP6qxFydr60S2Ldi/TUAMjswnWoa5S21xbT zg3oJ6Wt6aosqIH4AE3MQwNNGMO15fVL7X4zKQS6dLoXkNunHAd+VdZV2+eynehmE8 W2am0k/V3gHzbuZsf+VBhXoMk5rpkB6NWzphWhYcvUeJCVv2GnTPvbbHA0xZ2hQNWA jEMRb8CcRDLoA== Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C6423120804; Sat, 10 Jun 2023 11:49:44 -0400 (EDT) From: Stefan Monnier In-Reply-To: <83a5x81m33.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Jun 2023 22:18:08 +0300") Message-ID: References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> Date: Sat, 10 Jun 2023 11:49:43 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.124 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Alan, Could you explain why/when we need to call `Fset_frame_selected_window` in the code below: > static void > minibuffer_unwind (void) > { > struct frame *f; > struct window *w; > Lisp_Object window; > Lisp_Object entry; > > if (NILP (exp_MB_frame)) return; /* "Can't happen." */ > f = XFRAME (exp_MB_frame); > window = f->minibuffer_window; > w = XWINDOW (window); > if (FRAME_LIVE_P (f)) > { > /* minibuf_window = sf->minibuffer_window; */ > if (!NILP (w->prev_buffers)) > { > entry = Fcar (w->prev_buffers); > w->prev_buffers = Fcdr (w->prev_buffers); > set_window_buffer (window, Fcar (entry), 0, 0); > Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); > Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); > /* set-window-configuration may/will have unselected the > mini-window as the selected window. Restore it. */ > Fset_frame_selected_window (exp_MB_frame, window, Qnil); <<<<<<<<< > } > else > set_window_buffer (window, nth_minibuffer (0), 0, 0); > } > } I understand why we do the `set_window_buffer` and set its start and point, but I can't see why we'd need to select the mini-window: presumably if it needed to be (re)selected that should have been handled by the window-config save&restore, no? Stefan From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 17:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16864169907265 (code B ref 63967); Sat, 10 Jun 2023 17:10:01 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 17:09:50 +0000 Received: from localhost ([127.0.0.1]:36188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8262-0001t7-9P for submit@debbugs.gnu.org; Sat, 10 Jun 2023 13:09:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39530) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q825x-0001sr-HC for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 13:09:48 -0400 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 1q825r-0006LU-Cs; Sat, 10 Jun 2023 13:09:39 -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=w/lN/Z4gZp5HxmSn5mqDmf7hexK/R3U/aqd+tVcNc+E=; b=W0rOX4jJKSiI Y0OxK5ipC4rRFzVbHKWxOLCV3EC9PPe1XYhVAEi/QRTr4l1msh2x5dA5RuVvdaDg8VQ/tdEvNP6Iy xZy+5dDdgDGTr4rWCANAJv97Cg+Agt5I1pVTVgeL1PL7QpXE8qXjwO/3duc1yEKQYzcWpH0hPM9xR i72NJn+w2TmydGTLfmyXWoigzigrgjp0SNU9gC2Q/fuA7O9yLKxoCR/vrI2OBWz2/p8Mikz0xnVeN 2Vk4dtxBaIOb7Wou5zxn57HstIaSzJhCuB74LnMBBhJ20AwA90WPPzVO4jGmgQk62xNtaCL6Rh5z3 Y80xXXi7VobfuFM1diVLEA==; 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 1q825q-0002gu-TB; Sat, 10 Jun 2023 13:09:39 -0400 Date: Sat, 10 Jun 2023 20:09:49 +0300 Message-Id: <83jzwbz1k2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8a540045-0f14-43cf-0515-4dcab2f68b98@gmx.at> (message from martin rudalics on Sat, 10 Jun 2023 16:51:47 +0200) References: <83o7lo28e6.fsf@gnu.org> <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> <83y1krzpoy.fsf@gnu.org> <8a540045-0f14-43cf-0515-4dcab2f68b98@gmx.at> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 10 Jun 2023 16:51:47 +0200 > Cc: al@petrofsky.org, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org > From: martin rudalics > > > That works, but does it make sens to do the other stuff in that if > > clause in that case? We do: > > > > if (!NILP (w->prev_buffers)) > > { > > entry = Fcar (w->prev_buffers); > > w->prev_buffers = Fcdr (w->prev_buffers); > > set_window_buffer (window, Fcar (entry), 0, 0); > > Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); > > Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); > > /* set-window-configuration may/will have unselected the > > mini-window as the selected window. Restore it. */ > > if (!EQ (orig_selected_window, FRAME_SELECTED_WINDOW (f))) > > Fset_frame_selected_window (exp_MB_frame, window, Qnil); > > } > > > > Does it make sense to manipulate the buffer, window-start, and > > window-point of WINDOW if we are not going to make it the selected > > window? > > If w->prev_buffers gets us the right minibuffer to display here (any > former dw->prev_buffers = sw->prev_buffers should guarantee that), then > for that buffer we have to establish the corresponding start and point > positions. This makes sense regardless of whether the minibuffer window > will be selected or not. But read_minibuf_unwind already does all that when it restores the window configuration, doesn't it? Or is there something about the mini-window that restoring window configuration doesn't handle correctly? From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 19:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: al@petrofsky.org, rudalics@gmx.at, Eli Zaretskii , 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168642613823134 (code B ref 63967); Sat, 10 Jun 2023 19:43:02 +0000 Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 19:42:18 +0000 Received: from localhost ([127.0.0.1]:36352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q84TZ-000614-PX for submit@debbugs.gnu.org; Sat, 10 Jun 2023 15:42:18 -0400 Received: from mx3.muc.de ([193.149.48.5]:21475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q84TU-00060m-8H for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 15:42:16 -0400 Received: (qmail 74841 invoked by uid 3782); 10 Jun 2023 21:42:05 +0200 Received: from acm.muc.de (p4fe1580b.dip0.t-ipconnect.de [79.225.88.11]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 Jun 2023 21:42:05 +0200 Received: (qmail 9940 invoked by uid 1000); 10 Jun 2023 19:42:04 -0000 Date: Sat, 10 Jun 2023 19:42:04 +0000 Message-ID: References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Sat, Jun 10, 2023 at 11:49:43 -0400, Stefan Monnier wrote: > Hi Alan, > Could you explain why/when we need to call `Fset_frame_selected_window` > in the code below: > > static void > > minibuffer_unwind (void) > > { > > struct frame *f; > > struct window *w; > > Lisp_Object window; > > Lisp_Object entry; > > > > if (NILP (exp_MB_frame)) return; /* "Can't happen." */ > > f = XFRAME (exp_MB_frame); > > window = f->minibuffer_window; > > w = XWINDOW (window); > > if (FRAME_LIVE_P (f)) > > { > > /* minibuf_window = sf->minibuffer_window; */ > > if (!NILP (w->prev_buffers)) > > { > > entry = Fcar (w->prev_buffers); > > w->prev_buffers = Fcdr (w->prev_buffers); > > set_window_buffer (window, Fcar (entry), 0, 0); > > Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); > > Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); > > /* set-window-configuration may/will have unselected the > > mini-window as the selected window. Restore it. */ > > Fset_frame_selected_window (exp_MB_frame, window, Qnil); <<<<<<<<< > > } > > else > > set_window_buffer (window, nth_minibuffer (0), 0, 0); > > } > > } > I understand why we do the `set_window_buffer` and set its start and > point, but I can't see why we'd need to select the mini-window: > presumably if it needed to be (re)selected that should have been handled > by the window-config save&restore, no? There was a problem with the restoring of the window configuration selecting a window other than the minibuffer; that is in circumstances where the minibuffer window should have ended up being selected. Fset_window_configuration seems to be the troublesome function in this scenario. As well as setting the window configuration, it also selects a window. Perhaps we should modify the minibuffer code to note which window should be current after the completion or abortion of the minibuffer read action. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jun 2023 05:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168645980213970 (code B ref 63967); Sun, 11 Jun 2023 05:04:01 +0000 Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 05:03:22 +0000 Received: from localhost ([127.0.0.1]:36548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8DEX-0003dF-J0 for submit@debbugs.gnu.org; Sun, 11 Jun 2023 01:03:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8DEU-0003cv-FJ for 63967@debbugs.gnu.org; Sun, 11 Jun 2023 01:03:19 -0400 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 1q8DEO-0007IB-6f; Sun, 11 Jun 2023 01:03:12 -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=ATElBZtHKqpTaLXk30XaWLeVqon/lt/RlMvWPkC2HFM=; b=itBDDSp0Vrvy TguTpI5jSmTUjg2qA2o7txcQ3Ap2eDifpdo34h6nqFSc5jU0a8E5fTAUDRvEhwhxoCkw9RDl0eHZd Nwj0YjNBVwsGwYhImpLThy5sTSAgqIFSRH3WTrI/sxrma1/UEcQODklvg1Ck8bLBJMwV1y11wyXhW pifhlzJMlMOF4umc41xBfbDxXOsb4i/47VHsdMeXefIFR0rhH8O/AZF+i7K2j8bjAqz7oY9OrcE8I qNMT6l1kdP0Jp47uGePQ8rVximwecvThj5L+EkAAlqRvSqBOBRD2cKUuzFnYz/gN9VgiBXHwiUPlT nuv66pOt4KQIrXbSVjBUsg==; 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 1q8DEN-0000OT-Kv; Sun, 11 Jun 2023 01:03:11 -0400 Date: Sun, 11 Jun 2023 08:03:23 +0300 Message-Id: <83a5x6zj38.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Mackenzie on Sat, 10 Jun 2023 19:42:04 +0000) References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 10 Jun 2023 19:42:04 +0000 > Cc: Eli Zaretskii , al@petrofsky.org, rudalics@gmx.at, > 63967@debbugs.gnu.org > From: Alan Mackenzie > > > I understand why we do the `set_window_buffer` and set its start and > > point, but I can't see why we'd need to select the mini-window: > > presumably if it needed to be (re)selected that should have been handled > > by the window-config save&restore, no? > > There was a problem with the restoring of the window configuration > selecting a window other than the minibuffer; that is in circumstances > where the minibuffer window should have ended up being selected. > > Fset_window_configuration seems to be the troublesome function in this > scenario. As well as setting the window configuration, it also selects > a window. Where is that problem and its circumstances described? Is there some bug number or a discussion on emacs-devel that you could point to? > 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"? From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jun 2023 08:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16864710331581 (code B ref 63967); Sun, 11 Jun 2023 08:11:02 +0000 Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 08:10:33 +0000 Received: from localhost ([127.0.0.1]:36648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8G9h-0000PR-1O for submit@debbugs.gnu.org; Sun, 11 Jun 2023 04:10:33 -0400 Received: from mout.gmx.net ([212.227.17.20]:55101) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8G9d-0000P8-S1 for 63967@debbugs.gnu.org; Sun, 11 Jun 2023 04:10:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1686471019; x=1687075819; i=rudalics@gmx.at; bh=irjTfH+TUx9PrzvIEznB0SBOyOSN/gTtka0HDBeZSr8=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=O8yLsTEZSE6+ksWMWJgQ8LdqxA1YO/QmIet+iNlDRBAk6FCEWY5ScvooppTrIroeRHC+AkV /Qr06TKTrcBWDpKfvs0+5CF2SVpLz0UeEgH28DUNSiiUebTaU+bwrwj5LUp9xznm/Sfs9r9yY ciMGvJGMRvA9jufwZl2J+Gt3oplKSxMEjj3ZUY937CxG3sdwdgSotzcZ7iAa9zXnE2s3BbYF3 zbVPY2dNIfgIBQr9O/ugpgGWaFVEJDlfAsmhbFdt6kALSsX+NxMUzeQf/KL6CWplgwY/b0qa3 nKYUHi85e7FbnDmuUzYs91EEJrBW+XnSjVQrMJzKFDbSp/boveVg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([46.125.249.120]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MGhyc-1qM3vF2byc-00Dmvg; Sun, 11 Jun 2023 10:10:19 +0200 Message-ID: Date: Sun, 11 Jun 2023 10:10:17 +0200 MIME-Version: 1.0 Content-Language: en-US References: <83o7lo28e6.fsf@gnu.org> <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> <83y1krzpoy.fsf@gnu.org> <8a540045-0f14-43cf-0515-4dcab2f68b98@gmx.at> <83jzwbz1k2.fsf@gnu.org> From: martin rudalics In-Reply-To: <83jzwbz1k2.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:GSFuzl5AWyvhiTGor/IgedL3gKyIvpGP2NGbF3N69a6LraP9sks rEq5xDPbDFM7XcnmjW7qPa1qO4QcsjaJ1WoJqtOxjKbfzngW/R3hs993YN8I4xX+CTyLmNv aivPBpBA/LyRJJryAU4KB78CK0tM3YwBu6Tnw5TnAFZax5F2QRH++gP9dQyWQvIXvLOiwd7 kNJTq9JwdI3Bp/NYAgvFQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:qkDpLxtDr+U=;Cgy6mJRyhNrW9TyBv4vcBr8fdSe AJNdoDgYrnnctGc0qIj6fc1vKrRubBMwP7+3UwVaWLE2lLV/aNzn/SLKL5Qkl07RDSA89H8Lv wtl+sKdrRA+0j0OtkvNKZ7NRi77yisvfDAMIo4/qmZxiTcd9rRkcJgNwsHzBOR283V/O0OmZQ XoWWWX2UuQebN2dTX6e6u1QwOx9ZLflACI2OqlAGYWM8hnLqYM4jZwiEpeBH6fnYwRhJrWSdK +A8Ify3eywhq7gndE5FbWmcgJ5epAqebKellJg+NgZgK3WuI3CxnuNrzIaOBKBh4wfDvBrijk /KbAbtaECno6iipJoDp2XKro7wkstGhE91feJ/J1pnnAAjummge3y/t9vpgNVgkT6QWRyaZ9A SFLVCEZJwnw1IFz4Qcm6GsxyWotq/7B7N5BorlEwltCI4c/qjxxMFKM7j6KXMsaJ9z96YdVH3 wrzLAY8ipaEzyquClDGIoVw8xCzL+UapcXUd+MLTlWCgr6o6Kf80l47QOYsoCm/JVQvgaOkri oTdl0YswMahwx1Ka/G00eGP8V+LswofywCDTw5vXXq5J/9FouTJHDEcx1hvHD4Pvi8AfosE73 IYxFqsH7KI3uACwVhJLXe/Aqm9G9FbjIpj6lbR/m+PW/18782Ng2CiWjXpDiu0bDWzYgZttB2 sCu5hRSSmw30bIPiUr7mZaiPpqJ1la4dx6hpx8m7AfOvWXIEQP+f46NTEYUHIXKTAVu4Lkvvl XogJ8Ey94QRudjFc6ic/g5H8WX0EQeVwptbVUoXLOYgexZtKRoMnkZcOqJKJOTvRcuYLsfMt1 3m6jnjQtKO+lbPuSar9wDQC1JJrcUPJXiNq0GyQNb0wh50N0P4J2rMHimEhF3Z8pWasQmvYtR G763WZ2IkBDxqQ5PQK6uDj5XsvqZay3JCvd3U13IbXZDbRa/F06lY5zVKn1H68msbj/8DXK96 kPCJZUxx8/WsWHvqqoBL1ZHbuJg= X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) >> If w->prev_buffers gets us the right minibuffer to display here (any >> former dw->prev_buffers = sw->prev_buffers should guarantee that), then >> for that buffer we have to establish the corresponding start and point >> positions. This makes sense regardless of whether the minibuffer window >> will be selected or not. > > But read_minibuf_unwind already does all that when it restores the > window configuration, doesn't it? Or is there something about the > mini-window that restoring window configuration doesn't handle > correctly? I can imagine the following scenario: read_minibuf saves and restores up to two window configurations - the one of the frame from where it was invoked and the one of the frame that owned the corresponding minibuffer window at that time. Now with 'minibuffer-follows-selected-frame' non-nil there might be another frame the user may want to continue the interaction with and the configuration of that frame will not be automatically restored upon exiting read_minibuf. Yet, the minibuffer window on that frame should be restored properly to show its previous buffer, point etc. martin From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jun 2023 13:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168649086213509 (code B ref 63967); Sun, 11 Jun 2023 13:42:01 +0000 Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 13:41:02 +0000 Received: from localhost ([127.0.0.1]:36855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8LJV-0003Vm-JH for submit@debbugs.gnu.org; Sun, 11 Jun 2023 09:41:02 -0400 Received: from mx3.muc.de ([193.149.48.5]:52873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8LJT-0003VD-Iw for 63967@debbugs.gnu.org; Sun, 11 Jun 2023 09:41:00 -0400 Received: (qmail 15621 invoked by uid 3782); 11 Jun 2023 15:40:53 +0200 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 15:40:53 +0200 Received: (qmail 10752 invoked by uid 1000); 11 Jun 2023 13:40:52 -0000 Date: Sun, 11 Jun 2023 13:40:52 +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 Content-Disposition: inline In-Reply-To: <83a5x6zj38.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Sun, Jun 11, 2023 at 08:03:23 +0300, Eli Zaretskii wrote: > > Date: Sat, 10 Jun 2023 19:42:04 +0000 > > Cc: Eli Zaretskii , al@petrofsky.org, rudalics@gmx.at, > > 63967@debbugs.gnu.org > > From: Alan Mackenzie > > > I understand why we do the `set_window_buffer` and set its start and > > > point, but I can't see why we'd need to select the mini-window: > > > presumably if it needed to be (re)selected that should have been handled > > > by the window-config save&restore, no? > > There was a problem with the restoring of the window configuration > > selecting a window other than the minibuffer; that is in circumstances > > where the minibuffer window should have ended up being selected. > > Fset_window_configuration seems to be the troublesome function in this > > scenario. As well as setting the window configuration, it also selects > > a window. > Where is that problem and its circumstances described? Is there some > bug number or a discussion on emacs-devel that you could point to? I remember such a discussion vaguely, but after much searching, haven't been able to find it again. Sorry. > > 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. In read_minibuf (the meat of the minibuffer processing), there is a variable calling_window which records that window. It gets pushed onto the binding stack (along with a lot of other variables) around the recursive edit, and then possibly restored in the unwind_protect function read_minibuf_unwind. However, restore_window_configuration overrides it, because of the order these things are pushed onto the binding stack by read_minibuf. Do you want me to fix this bug? It seems there are quite a lot of people who've made observations about it in the last couple of days. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jun 2023 13:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168649162614970 (code B ref 63967); Sun, 11 Jun 2023 13:54:02 +0000 Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 13:53:46 +0000 Received: from localhost ([127.0.0.1]:36861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8LVq-0003tN-4P for submit@debbugs.gnu.org; Sun, 11 Jun 2023 09:53:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8LVn-0003t7-Cb for 63967@debbugs.gnu.org; Sun, 11 Jun 2023 09:53:44 -0400 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 1q8LVf-0002nE-UP; Sun, 11 Jun 2023 09:53:35 -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=+q/H9QiYGYIwG5IsQSmWv411Z4bfV3jRlGmw2xXOEtU=; b=gGjQmHNkXuip d8eA1G+FhACgEt5CZVMphcWBEYhjm7T0FgcwfWHfySYtrP/wniI3dhemxYnAt2thuUKVFsVNtMNv9 bIIiLmcfQQosc7+ji4K7lg4fpNYPOq+5bQWPg316T9li9cuJ6Ktm9IYWExDry8DmiWOdQ6L3kMsww BP3s+0SL6IdsLtsfW465ww74TnxRJAaDRZLs9n3A3etVPLZehBYcRFpkVuPpX5Y/LVkispXyLXuXr PBUrwcujGCuzAC5cKSSDpuldQ7mq70GahDWB+TzpqgphT9cu+12BV+kBxoVKxzDGm+68Tbs1NNCQF FxoqJnl8o8LT0YVvdgiMEA==; 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 1q8LVf-0003xb-EO; Sun, 11 Jun 2023 09:53:35 -0400 Date: Sun, 11 Jun 2023 16:53:48 +0300 Message-Id: <83zg56xfyr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Mackenzie on Sun, 11 Jun 2023 13:40:52 +0000) References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 11 Jun 2023 13:40:52 +0000 > Cc: monnier@iro.umontreal.ca, al@petrofsky.org, rudalics@gmx.at, > 63967@debbugs.gnu.org > From: Alan Mackenzie > > > > Fset_window_configuration seems to be the troublesome function in this > > > scenario. As well as setting the window configuration, it also selects > > > a window. > > > Where is that problem and its circumstances described? Is there some > > bug number or a discussion on emacs-devel that you could point to? > > I remember such a discussion vaguely, but after much searching, haven't > been able to find it again. Sorry. Too bad. If someone can find it, please speak up. It is important to know what those situations are to make sure the solution we install for this bug doesn't break those situations. > > > 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. So you are saying that minibuffer_unwind exists only for the case when that window no longer exists? But if so, where's that condition being tested, in a way that minibuffer_unwind is a no-op if that window still exists? > In read_minibuf (the meat of the minibuffer processing), there is a > variable calling_window which records that window. It gets pushed onto > the binding stack (along with a lot of other variables) around the > recursive edit, and then possibly restored in the unwind_protect function > read_minibuf_unwind. However, restore_window_configuration overrides it, > because of the order these things are pushed onto the binding stack by > read_minibuf. I don't understand the need for recording that window separately. The window configuration restored by restore_window_configuration is supposed to record it. > Do you want me to fix this bug? It seems there are quite a lot of people > who've made observations about it in the last couple of days. I want to fix the bug whose recipe is in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#5 and other similar ones, yes. Basically, if Emacs reads from a recursive minibuffer when the selected window before that was not a mini-window, we now signal a user-error, which is a regression since Emacs 28, and I'd like that to be solved. But please begin by looking at the solution proposed by Martin in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#38 and tell if it looks good to you, and if not, why not. I'd also appreciate more commentary explaining the rationale for minibuffer_unwind and the situations where it is needed. But that is less urgent. Thanks. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jun 2023 14:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie , Eli Zaretskii Cc: "al@petrofsky.org" , "rudalics@gmx.at" , "monnier@iro.umontreal.ca" , "63967@debbugs.gnu.org" <63967@debbugs.gnu.org> Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168649416920031 (code B ref 63967); Sun, 11 Jun 2023 14:37:02 +0000 Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 14:36:09 +0000 Received: from localhost ([127.0.0.1]:37599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8MAq-0005D1-Jb for submit@debbugs.gnu.org; Sun, 11 Jun 2023 10:36:08 -0400 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:20050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8MAm-0005Cr-TB for 63967@debbugs.gnu.org; Sun, 11 Jun 2023 10:36:06 -0400 Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35BA8YOo004078; Sun, 11 Jun 2023 14:36:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=r0E7LS4IuvneTX4VjxeL4tjR6Z54NuBJ6i1FB6NCXFc=; b=RZaDGKxtkFgPoyD/ZAU3/hud4ecUIc1MLm+WLJEmsV+TwKIkDidO5YixxnDY05RJgpE3 Tz0KnXDAINdW+Wm4Maj2h8tsv6PZ9wVVnDEsDkBv02/5dSTyG+/Hc+S/MNLzTOTRsj9I sz33j8Cm46ILn6Bpr+TCPAV4hqgV6EGdM2hhhDQFy4XmnCY0el5fo3CCQ7Sib88ffy9Q qY5uytfA3GGbFVCjbKHS9cd1nPLegmtReqiHSSP+I7446IBuTFsMafO+VEqmK0fd86b3 sBZNtRc/5Jmyg1+aeuS4PWRts1ZWoPLMzZwmNIoxq+lJiks7v0DrIeWrbxW+75E3pfeW HA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3r4gstsbk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 11 Jun 2023 14:36:03 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 35BD2P4Z016215; Sun, 11 Jun 2023 14:36:03 GMT Received: from nam04-mw2-obe.outbound.protection.outlook.com (mail-mw2nam04lp2175.outbound.protection.outlook.com [104.47.73.175]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3r4fm1wvrp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 11 Jun 2023 14:36:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I0z4RUiKNQv/8hL0CdbG4Sm1IZAaKSxEYzXVMNbnD6Mg1jaQzbGhZ9FVB/kl+Kp59et0oaqANnx/XrJUfXSM2oBEOW5a2NdvR3oX3d+pA8xZMeQOyjnN8+5JxVrVRqiVQzMY5A+71vzHhYkYrt9ok1L2jHFmQtEGwjfejScBhgU7dH/0+nXTMK0ZCeZFPvimRTZQwnz03Ad37R8we3s0d6lKbGmFenWWmLR2rlL2/+4C5uDXFCx7MNghZVwGNj8t+bhzbCsFdTMquVYn8Z89MeTqHJ6toRKo8rEQ1PDCYkuJmtMtK9SelVljuWv2HQ59rZQtzzgsPzUEFWeQQTDhFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r0E7LS4IuvneTX4VjxeL4tjR6Z54NuBJ6i1FB6NCXFc=; b=Y7Qx7Y/TTdtfp2Xc9jjUf2HkfOznRB9QZomJnlEJUwn37nJJmZV25gNcR2YbIg/DrAzEUqMhveQX4Ns7AiSuZdiXPNDxYz4iv9oKTKUYruuMOIJuRY3E5APiNrViWRy64wwCMQuBVheUKOtCGtdkSm21Z8qdyB1jXV0s1FI4xbGLzwQEe+sXcRTbuYYF4gnrmLfw1puNwYN+6Ne0e0vYBM94IusYTy2B5J0SRAtzMEGnAPgKhmZuBHttF0vxfKkc/YVv7xSeDVmb/7K3OWTRC8HKATHz005cJtsUnfXl7ZIHLWxcOA4KN0Uq6gFiLKc5GqIBVd/Nx967bbSZd/bheQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r0E7LS4IuvneTX4VjxeL4tjR6Z54NuBJ6i1FB6NCXFc=; b=pO2vhPv6+C2UA0ih4bfHSmUZpuUekVVHwWCOf8szU8tVdjFcq8s/FB/g9XExLuWN7kWpVEF0gCQlAUnVY63GVOOU0xnRVWOiS1TIVqWZMIOSkq8VrJYOk0bc1PBTyEGY0cmAKZuUTYhDCVCfe74o2mpf0i/kqt4wNOqJtGBEB9o= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by PH0PR10MB5705.namprd10.prod.outlook.com (2603:10b6:510:146::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6477.29; Sun, 11 Jun 2023 14:36:00 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::dc5:6c42:cd71:3909]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::dc5:6c42:cd71:3909%4]) with mapi id 15.20.6455.037; Sun, 11 Jun 2023 14:35:59 +0000 From: Drew Adams Thread-Topic: [External] : bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Thread-Index: AQHZnGqMSGVoT80BOUWG+K7vhRRqy6+FnNCQ Date: Sun, 11 Jun 2023 14:35:59 +0000 Message-ID: References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR10MB5488:EE_|PH0PR10MB5705:EE_ x-ms-office365-filtering-correlation-id: b484d44c-dcdd-43b5-f3e5-08db6a892ca4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MiFkAfBKQ+CPbjLoGBHdcrM+GYBZkzCGMbqSiDKMtfVuAKFzH18BKjTg/4sunIN00B6ltJR2m60P8V9aLml/ZwZo3HPnQeh5mv4v6zo6Itia09+vXSpJRDYURBn/5/z2uBqwt4xrUBoo/2491KcpFkq95oBBYPgz1YKqJrVHkdHM5G4ot0hzWtH0FCop25H/d6XTxgE7lSzx3p0lNuc6J42hrkNIHq4WMkJF4qpXm/mzEa+F3lnFMBX0J+vQFQgFD5Gn8kC4pYN9qJmbaUDRa9h5+XcOsEvPC+0NaJe7iivt6TqacN1lJfCC6zxQSz4XI7wxWASfioyPnxtZiziEnBRzbX53HN2y/6k2jzyRkBg13MJFyFBPWvy61IVEUVTXC391iF0jMJS8h/86O2rxwI7C4UfV8UNkydpTFJLEqHJer91WDv0RLfKs1Ka6lkHztPkRdIpZjNxX30sjyvrObT4H/kKG1wyKlBE/eRBWz+l+d6dCA70XwLvvMg/0uievS2sX8ASsI7bj9J+Rc8sXDgoh8FPLFMlxwCvyxi1tmek4RTxQRQejy12Y/16e4eM3rry2c2R0HN7KmF0WEJHZ6vestmxVbOnwxURnkqSEgFqGPbJJiRSECt7Vxqb9x62V x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(136003)(346002)(376002)(396003)(39860400002)(366004)(451199021)(86362001)(7696005)(316002)(8676002)(41300700001)(38070700005)(5660300002)(26005)(55016003)(38100700002)(9686003)(6506007)(52536014)(33656002)(71200400001)(122000001)(8936002)(44832011)(66446008)(66476007)(66556008)(64756008)(4326008)(66946007)(76116006)(478600001)(186003)(2906002)(54906003)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: RTSghBOIG6VyX978IyxxzzCthE5eip7yRXpllCbBK9JzcV78xrRXa8n+42pDYxQPoDq+3JE/Wip5tg0Zw0m+v2x+Dwc2kdOp7UfsJKrvUdC953+XV0Mtx9dziPVKsn3HH/Mdx21y4296NftyEdEmOK0/6LkwBHMpdpV0IdKssft0b45jDNqZPTFqnbCX3s7HCM02FDvlXWmvDE1GuZEXbOHuEbDXZWPrhDqP0o8i2SxojYcvztKx+YpZafXtEhUxF1RHvEbl56YtoTEx/rUgjN2YH3Tj2fyHTZod5ZAfc+iXgeZf5oNPQpb6Pbk6KnaWQiG2hN47pRjEu4XyTx3g9BS8lr5Qdlbqa9psscSQZ1iimnCMGjeZiixl0mx9bWuo85SxSC1ES3CbdWGjdT7zkLv9ETkgkbvmfCFsYs2CT8DQZt/shfaUv7rd6V0eSXqHDgacKlYTuUzDNjqQPjiyuB2ParPsIzepvuPWQUbFgPBjAbcvcQAwbgB2a1I/B3GEpziXHytDxevgOPff0aILkahDrsn/NLMQcRnYqd5d0pi0CepwUAmYPRzKeFtDk7ftD1/m0YBy/ReHViQWUw5/eGWFnkLNVJCwZiX9kfwtJderxjnfoBwFDODtzxfFLIwWCnyQIRtMlvIzqP9kydbYadvYRcYlJzUGsLD09r3b1tcrRO36+/rY2soYZRAvARsmHYcZ+BIzSqaK9Dj9MeNfv7YiN3+DQNwmHbEzaYPKJRhJ1qVRtA7WDt6FbbFmKsMRVNF21gRldIvIUI+Yy3Vc7s3dR/PjIAUX7ercy0xA2190/Wxh1//czymyO747Oi+M5TB6kD1FFA6ReY1apdH8RgXBAkoJt6moebNtB1NBexUOeJxVnepl6Z7EDYQgDxoW0tuw/mH8r6TJTbApNoF7YHtB3hmVV+lXXjhdqqyb5h4nRxqBojIeDzME+TSVPHo/TlBEyygo4lF0E2cBF/QsThkMblceFX5p+kLBQBwoUVZdaovA5gVQ5efyky23RrUdl6NDkFAsYbVq9IO7H1IuyV7BoFYKaAE4+qHfrvtDP8VGJP6L3F0j+c1B8I0e6C9uSSUU8r2nVZ3fWGaUXDPVlh4dRVu/jWAfbX0UvmQARIHVRABKDYRVV2tm+makTUomysGXksyX+lZ0W1YrWYQSAssFNFfEX7YmyXeC+cTAnCrf6qU16NIkXePSGeZVTewJGI4Gpx0AqOQv7wpAEi6OybCQcutRRPWNkMDulaHhjITxi6pX7knX8djOAWZL9/VfrxcmZLdDyY/hSHbEFkmqV+XU4qktlRlKyjfJjeq4yI17R3R1ePZfPLhWD7UhcjX+cRDGWzM5onydUbOg5pDCC8Y03+OknCCWfiGVkZqpT7npw9EHKDEJZwT+0P0emU8y1jDYSP/KoXtg815oUDMXnrTF15tm8wVMIph4d/7tYSEO9VIIeOk6p4xEkhpYXq5ZRoLXZ9B+a8PswwHX1ETksQ7W3BgH+dzBmvNpgaHDSWSQ7vBkOGDp6GzdsiIo3hhIp0Vfr5bBHAHeY4uPoGKdrMsTgyRKEV++p/WSafRMRyHZYW5ukumsp8ylAgFAgbhG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: lnjmvVypWRZ2xi+qOA5tLrUrGpzutWg2xQv2RppTn2PJlLptOGWecoIw/bsxSVHQVrhejPdhPDxYAjFyasyuiimKIwkUHLE0Af0OaeQ4KgYpI+ANAmVevJOJUqVmCDc4CtZRlUsNSY5b5RUaLxiomJp5jMg9Sa2DXe/HppNah51POldNi0MCr7No8nRXtaOj1Mv5DFmdFLQpKVYe0CojrPM4zkJ1WR7FTKGmCcsjrv19HE4fMfKSe47xKsLmUJx9eygaJOANC2gOTTbQPCz+Ap89W8Ru2pfLnVHEH+PN4LBhfDgQr2wxeujgXt01SsN/agwUMBGQVTQNsm7Hi12qwdCGeRDlGD0PEPzgoK4df5h9AeDxGlR50vO4ErmrpVNbEwgq27FC2HP2jw3ar0x+DcIX72r37+lOruXIDa8oc7mo9+9oFh1qRfdMgXU11HTpx37eyvWqhEUwy58IRqSVYmjAb1mspLcMkFI8qbXBWFnnmNAWnrp1bAcC0GfRN+zx3lSsH8gLm08wh/CumhjdFFPzDBs78VkG3A+xMdgR1jHz8IaCcKbSS1uV0pZ48bKXfrW88zhBC9TQ7UbLK9Z0Gy81O0lzIu/3DwzLPzepbu0b7Dk4vSrUDdgLR1I/7qN6YWqeWzoY6bXqX8jpyzmi23W+99BTknOccpMqJRMGi1Lb9tX7YBAN+q1aGxr80X214GTOIM/Q8mo0W55KRzHaFVQapedywPdNVON4fyrHGntpvPueoWPmCdbKWRjmu+b4ITvb/dM8wRe3f0Lbku834fHwKdDCbdEUWxTTBzdNlrt6xRvxobcgIJedE4uLGGPtqN2eWYjMsPW/KWGBAO4/9uucJCWSxjeiGuAeqzcfp+5KeKhVKy8NEFn4npTMcA0y55koCeK6/H7ZNSWpNX/y7g== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b484d44c-dcdd-43b5-f3e5-08db6a892ca4 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2023 14:35:59.4910 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jwwfabgzinsgz6tI0XHKxnGFJI5nQHS3/zPhLChvIG7eP++PYurXaCDE5ISF/MmJV54H6C/KnQLo59QL5RkCrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB5705 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-06-11_10,2023-06-09_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=803 bulkscore=0 mlxscore=0 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306110135 X-Proofpoint-GUID: fPQzdfGUpDeNIXgoePlxfHeVQ4Dap1J8 X-Proofpoint-ORIG-GUID: fPQzdfGUpDeNIXgoePlxfHeVQ4Dap1J8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > > Perhaps we should modify the minibuffer code > > > to note which window should be current after > > > the completion or abortion of the minibuffer > > > read action. >=20 > > Isn't that simply "the window which was selected > > before entering the minibuffer"? >=20 > 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. It isn't "simply" _anything_ you can preconceive. It's _whichever window ended up_ selected after using the minibuffer. Nothing more, nothing less. 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. 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. 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. 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. 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. 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. 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". The Emacs minibuffer was "simply" better before you simply "fixed" it. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active 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 X-GNU-PR-Keywords: To: Drew Adams Cc: "al@petrofsky.org" , "rudalics@gmx.at" , Eli Zaretskii , "monnier@iro.umontreal.ca" , "63967@debbugs.gnu.org" <63967@debbugs.gnu.org> Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168649928829634 (code B ref 63967); Sun, 11 Jun 2023 16:02:02 +0000 Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 16:01:28 +0000 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 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 Received: (qmail 76409 invoked by uid 3782); 11 Jun 2023 18:01:19 +0200 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 Received: (qmail 11703 invoked by uid 1000); 11 Jun 2023 16:01:18 -0000 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 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active 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 X-GNU-PR-Keywords: To: Drew Adams Cc: al@petrofsky.org, acm@muc.de, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org, rudalics@gmx.at Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168649995630669 (code B ref 63967); Sun, 11 Jun 2023 16:13:01 +0000 Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 16:12:36 +0000 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 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 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==; 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 Date: Sun, 11 Jun 2023 19:12:37 +0300 Message-Id: <83sfayx9je.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Drew Adams on Sun, 11 Jun 2023 14:35:59 +0000) References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Jun 2023 07:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie , Drew Adams Cc: "al@petrofsky.org" , "63967@debbugs.gnu.org" <63967@debbugs.gnu.org>, Eli Zaretskii , "monnier@iro.umontreal.ca" Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168655427227415 (code B ref 63967); Mon, 12 Jun 2023 07:18:02 +0000 Received: (at 63967) by debbugs.gnu.org; 12 Jun 2023 07:17:52 +0000 Received: from localhost ([127.0.0.1]:38752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8boF-000786-Og for submit@debbugs.gnu.org; Mon, 12 Jun 2023 03:17:51 -0400 Received: from mout.gmx.net ([212.227.15.18]:48365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8boD-00077t-2p for 63967@debbugs.gnu.org; Mon, 12 Jun 2023 03:17:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1686554254; x=1687159054; i=rudalics@gmx.at; bh=oqsSIOI9T8yHDGDz4eljP29TJ5M/mVfi915qbjETydc=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=Y+d1jWyI9ohztbnL5LBBfN1+z3e8BNkyO3DP8yo51OTcFQTWxPxDR4n18uA5qRsHRFHFeKP DhuNN/oFJ5F5tAWsadp3snYfJhjdWkUq+R3ufYfEuz3MFREv8uabJbRDbuSPXeki3ZM5sr69q aflNlAXAXm6V1UKy7DTgQq1lFPeMoX3iCCePDHK/hFxNwx1qxNnHIIwe2JJ81cpbXJQsb+hjn Zzy0Ta7KIZopHItuvJzuZEDWRZjhtxaDOglrekExXpLvWEnExGCP+2lkqxGaX71MJa0UTAuQD v0YszJWrLg2K0iHD+8Uvlb+2w6FjpHbF3C7k0+RAsmmYWDv2JIOg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([212.95.5.157]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M7sDg-1qCTQV33H0-0052Vn; Mon, 12 Jun 2023 09:17:34 +0200 Message-ID: Date: Mon, 12 Jun 2023 09:17:29 +0200 MIME-Version: 1.0 Content-Language: en-US References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> From: martin rudalics In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Jg51rsSJhzl4UAaL5NVAzig/UeusqrI5VDvkiGXeHb0VSOh8gzV cAFkPo1tdAYt3SsQWLg2lBNGLHKeG7l50trVz9LBqWKD5xmgUdwl7z02OHx1T7vlwS47Dzy kcPVMCmLEXuKRN2zGbBp4b0d3QOcvEF02mqMfD3F0+vg1FBxCWtdgptxMwL7EipiTOTy6MY 9A/Wa6NYbk1ZlAUJI+edg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:x2hCUDJCFK0=;IIBM9ejTWF+DBqvM7BlWncO9Jl8 oX+e11i3Y1RLCaD2+uewzegRegosy8RkCUqAXOZfZgwZMFi+4d6WoRY20vR11JwFz3VeSgmkd 6y/0CWlNmiNRB4r8c0dTDacTNbRrRfMjxGIWcMspf9tJ4MaW1jBh8erx5HNmUT8qZHsRzneDK F1JHY5l+ATOhSZB7RDTpmiNYJ51egdx9gpyAPjY8EYmT2gjFH21ib15xTmRWB1lNeoN5NjWwx yOIKViD3rTAR3B7ntgOCIf8iElJmEN/+eCDxmP8cV1bAcJDpoSThkaUilQ8Kv2MG1rkhBw8/8 hIYvwluVF0rrWWNVB6tgFsqtSujskUufre+QvoBMq8HPQnjlnGmxbCZkaqXoaTDkOvcXK2bEj 7C7oEmlquy0edozbbvvGA2MS714Em3b0aggI5LbUT4JReG1LYcl0JbZBkaR8cRrD2FfEpOsJs jsmzgznat+4KzR7HxoXoBz9uzc1417Cq5dNmWRGyfsjqehSai0WlhjIA97m9RgtPXq18BAiKG 3Vv0DV+fC1yZvNeIoUwuIpPXwnnxr8KkqqZYXmdZoVt0VHjFdq+UI3Embo3emwjI9XoRPsC+c /6ADf8tYA3mOHHxJJeUPIbJFklgEZ+sDme8oot5LX2Yf9XcChf8nKo5YNKmpQPYSyQ9GyJYKM f3OwyTZftBrM8jcsOXQ2HQtMbzmgEd+rrf41Cjfey6oCoNpLqkqerSH6mq9i6Fvf8b1y/Pk68 /Dt3voh+aISxcCdScnqgOlkKxv4z5SCT6OAVnGp+woZcwDyYtdmfBsMfS/nu5FtRy5rppYaCW c97o5pmGNbc6mFzOu3fv2TFP+uN5WFKmhR6p8FNwXAJjG6WK64XgI6A1uQW7BusBfxlCjy2/l XKI9ncDB+dEpB0dtkEAaMeIXqFJcVn3FJqS6jLk3NNUY7LY57SUoX2QE6blx2B7QdS+Tr18Rb xzu0yPlNR5P5k7N1jn8947ESd7Q= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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. Alas, this is no longer true. Start Emacs 29 via emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" Now type C-x 5 o to switch to the normal, minibuffer-less frame and then type C-x f. Next try to access the normal frame via C-x o, C-x 5 o, the window manager's Alt-TAB or any other key combination. This used to work ever since. Now you are in a modal dialogue exactly as described above. martin From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Jun 2023 12:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: al@petrofsky.org, acm@muc.de, monnier@iro.umontreal.ca, drew.adams@oracle.com, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16865714992494 (code B ref 63967); Mon, 12 Jun 2023 12:05:01 +0000 Received: (at 63967) by debbugs.gnu.org; 12 Jun 2023 12:04:59 +0000 Received: from localhost ([127.0.0.1]:39130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8gI6-0000eA-VS for submit@debbugs.gnu.org; Mon, 12 Jun 2023 08:04:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8gI1-0000dn-DQ for 63967@debbugs.gnu.org; Mon, 12 Jun 2023 08:04:57 -0400 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 1q8gHt-0004Mn-Jk; Mon, 12 Jun 2023 08:04:45 -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=3+BpNJExAf4DSVMSNCffqdaBF04WTzJ6yaP255jchPo=; b=r9cdpLL7Hihl pMf7YTRZLfYidONIipNfJ+zJnPioi0oQXpRXJI1HlmV7idNQ6UmKmf9miBIlZMqarI3zzlhh8P2w3 b6bCfDJOHR4UJqmEPApTeFWJHwQ34T6E75kCPwtRzSoWhrQabi7UUqlx67CIO970Tnp8rgAv8+JpY nToBf807TSOPuI4Cci5EX6V6jiTS9sTsHgSyx3z+JH1Sr74UMJe5U9i/xt1g7SWyrVMZSGh72vdKE z+jUn/L/FO9wq7aPSIFNmHO9TUWP7+RLbH+a6ZyStEZasD4fyVFMaVJS7Zh/LgX2ulSt46lz12Uct 73T1/LKTPS7Psh28rnCEQQ==; 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 1q8gHr-0004w9-NW; Mon, 12 Jun 2023 08:04:44 -0400 Date: Mon, 12 Jun 2023 15:04:57 +0300 Message-Id: <83ilbsyjh2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from martin rudalics on Mon, 12 Jun 2023 09:17:29 +0200) References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 12 Jun 2023 09:17:29 +0200 > Cc: Eli Zaretskii , "al@petrofsky.org" , > "monnier@iro.umontreal.ca" , > "63967@debbugs.gnu.org" <63967@debbugs.gnu.org> > From: martin rudalics > > Alas, this is no longer true. Start Emacs 29 via > > emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" > > Now type C-x 5 o to switch to the normal, minibuffer-less frame and then > type C-x f. Next try to access the normal frame via C-x o, C-x 5 o, the > window manager's Alt-TAB or any other key combination. This used to > work ever since. Now you are in a modal dialogue exactly as described > above. Probably a bug that needs to be reported and fixed. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Jun 2023 18:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: acm@muc.de Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16866817867854 (code B ref 63967); Tue, 13 Jun 2023 18:44:02 +0000 Received: (at 63967) by debbugs.gnu.org; 13 Jun 2023 18:43:06 +0000 Received: from localhost ([127.0.0.1]:43072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q98yv-00022c-Vy for submit@debbugs.gnu.org; Tue, 13 Jun 2023 14:43:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q98yt-000226-2t for 63967@debbugs.gnu.org; Tue, 13 Jun 2023 14:43:04 -0400 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 1q98yl-00031o-WA; Tue, 13 Jun 2023 14:42:56 -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=mUICCvV2tHYJIk0JSYyLZr5vK/OO3MLHNUuUMzm0SdY=; b=my9xYixJni5F rtNZsKHHbyGq1UfZgOAN+rOLZhV8uAbQZm6z9ic3XxyerhWp8kjmcUoR4hDteAs8NChqNsCDgnLJk 5PSG72RSWYbsFshr4L+ajqc37rpBuKD/I98AJj0YUpLUmTS5iM0DYPrJrNcSqr7A3lOhZk4T8GPN7 oOozsdKbBFR2fB5QKTCsCl8H9eYAJXwcBse3iulOP1oYZF3FwEmskWpArVYprbLvnzCpQbLVKz6Lh n1gunLcfP1DLEFqosUuQUGXlYVTnNbjwtN8Lhhs4qzKbhdk+YD+Zz23TAZdf2zgm+uMZtyrxy8dMp d/cLgheFpPLV+OPdCJ9m7g==; 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 1q98yl-00029I-Fj; Tue, 13 Jun 2023 14:42:55 -0400 Date: Tue, 13 Jun 2023 21:43:13 +0300 Message-Id: <83v8frursu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83zg56xfyr.fsf@gnu.org> (message from Eli Zaretskii on Sun, 11 Jun 2023 16:53:48 +0300) References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > 63967@debbugs.gnu.org > Date: Sun, 11 Jun 2023 16:53:48 +0300 > From: Eli Zaretskii > > > Do you want me to fix this bug? It seems there are quite a lot of people > > who've made observations about it in the last couple of days. > > I want to fix the bug whose recipe is in > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#5 and other > similar ones, yes. Basically, if Emacs reads from a recursive > minibuffer when the selected window before that was not a mini-window, > we now signal a user-error, which is a regression since Emacs 28, and > I'd like that to be solved. But please begin by looking at the > solution proposed by Martin in > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#38 and tell if it > looks good to you, and if not, why not. Ping! Any progress there? From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Jun 2023 21:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, rudalics@gmx.at, acm@muc.de, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168669220926147 (code B ref 63967); Tue, 13 Jun 2023 21:37:01 +0000 Received: (at 63967) by debbugs.gnu.org; 13 Jun 2023 21:36:49 +0000 Received: from localhost ([127.0.0.1]:43204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9Bh2-0006ne-E6 for submit@debbugs.gnu.org; Tue, 13 Jun 2023 17:36:48 -0400 Received: from mx3.muc.de ([193.149.48.5]:40374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9Bgz-0006nO-C7 for 63967@debbugs.gnu.org; Tue, 13 Jun 2023 17:36:46 -0400 Received: (qmail 16247 invoked by uid 3782); 13 Jun 2023 23:36:39 +0200 Received: from acm.muc.de (p4fe1589c.dip0.t-ipconnect.de [79.225.88.156]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 13 Jun 2023 23:36:39 +0200 Received: (qmail 11069 invoked by uid 1000); 13 Jun 2023 21:36:37 -0000 Date: Tue, 13 Jun 2023 21:36:37 +0000 Message-ID: References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83v8frursu.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Tue, Jun 13, 2023 at 21:43:13 +0300, Eli Zaretskii wrote: > > Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > > 63967@debbugs.gnu.org > > Date: Sun, 11 Jun 2023 16:53:48 +0300 > > From: Eli Zaretskii > > > > > Do you want me to fix this bug? It seems there are quite a lot of people > > > who've made observations about it in the last couple of days. > > > > I want to fix the bug whose recipe is in > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#5 and other > > similar ones, yes. Basically, if Emacs reads from a recursive > > minibuffer when the selected window before that was not a mini-window, > > we now signal a user-error, which is a regression since Emacs 28, and > > I'd like that to be solved. But please begin by looking at the > > solution proposed by Martin in > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#38 and tell if it > > looks good to you, and if not, why not. > Ping! Any progress there? Sorry. I've had a few very busy days in real life. Firstly, I'm reasonably sure that the Fset_frame_selected_window I put into minibuf_unwind was a mistake based on the misconception that after reading the minibuffer recursively, we always wanted to go back to the next outer minibuffer. I think Martin's patch (from 2023-06-10 08:52 +0200) is along the right lines, i.e. go back to the invoking window rather than the minibuffer window. But I'm not sure whether it might be better, from the point of view of preserving maintainability of read_minibuf, to try to get the restore_window_buffer_configuration call to go back to the calling window, rather than adding the extra parameter to minibuffer_unwind. It would be somewhat complicated by the need to go to some other window if that calling window no longer exists. We need to decide which window. This dilemma might have been what moved me to put that Fset_frame_selected_window in in the first place. :-( So I see the fix somewhat along the lines of removing the offending Fset_frame_selected_window from minibuffer_unwind, and maybe rearranging the calls to record_unwind_protect* in read_minibuf to arrange for the window configuration call to do the job of restoring the "current" window. It seems to me you might want to put the fix into Emacs 29. Am I right? -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Jun 2023 12:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16867449058341 (code B ref 63967); Wed, 14 Jun 2023 12:16:02 +0000 Received: (at 63967) by debbugs.gnu.org; 14 Jun 2023 12:15:05 +0000 Received: from localhost ([127.0.0.1]:43959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9POy-0002AT-Vz for submit@debbugs.gnu.org; Wed, 14 Jun 2023 08:15:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9POw-00029f-8g for 63967@debbugs.gnu.org; Wed, 14 Jun 2023 08:15:03 -0400 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 1q9POp-0005Sk-3Z; Wed, 14 Jun 2023 08:14:55 -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=OGwEeAEhN/YAAth2w+ekcspFLVO55FOt8z/7/861X4k=; b=gNVD0nkoJKIy BnnWN8B3GbIrLdQ/hkwVZwnv6lPGW+F6c5kNeeBWzLGpd5tJyiXL9xwdu6fChIRtyM1vfupgbgA6b VbTn7rJmw5AjC1VJOUYMP2MIZokzuxEen55Q1oD3QjzwNa+2cff97YKNe3sMM4ZlHFZ0LXstthofT VqSIt0R6r6q4KMct3Z4z32aNqkmnpf3ZiZ4LtGg05alPdYGzPT6R9lR4zE9/UWZhAaibgSjR6LPTn moHVRSEC3RNPIgUSC8g0Rc/O3YZDJjZjSoHU3eSnTjGbW1VclYDTA4qLPg2PFzE71DqTxcshdzW/Q EkwQkmIUwRvASjGGnEX2YA==; 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 1q9POn-0004C1-TO; Wed, 14 Jun 2023 08:14:54 -0400 Date: Wed, 14 Jun 2023 15:15:14 +0300 Message-Id: <83jzw6utnx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Mackenzie on Tue, 13 Jun 2023 21:36:37 +0000) References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 13 Jun 2023 21:36:37 +0000 > Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > 63967@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > So I see the fix somewhat along the lines of removing the offending > Fset_frame_selected_window from minibuffer_unwind, and maybe rearranging > the calls to record_unwind_protect* in read_minibuf to arrange for the > window configuration call to do the job of restoring the "current" > window. > > It seems to me you might want to put the fix into Emacs 29. Am I right? Yes. I wouldn't be pinging you if it weren't so. So I hope you will present a suggested patch soon, and that it will be simple and safe enough to install on the release branch. TIA. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Jun 2023 10:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168682471522216 (code B ref 63967); Thu, 15 Jun 2023 10:26:02 +0000 Received: (at 63967) by debbugs.gnu.org; 15 Jun 2023 10:25:15 +0000 Received: from localhost ([127.0.0.1]:46246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9kAF-0005lr-1v for submit@debbugs.gnu.org; Thu, 15 Jun 2023 06:25:15 -0400 Received: from mx3.muc.de ([193.149.48.5]:49438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9kAB-0005j2-UT for 63967@debbugs.gnu.org; Thu, 15 Jun 2023 06:25:13 -0400 Received: (qmail 60361 invoked by uid 3782); 15 Jun 2023 12:25:06 +0200 Received: from acm.muc.de (pd953a62e.dip0.t-ipconnect.de [217.83.166.46]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 15 Jun 2023 12:25:05 +0200 Received: (qmail 16845 invoked by uid 1000); 15 Jun 2023 10:25:05 -0000 Date: Thu, 15 Jun 2023 10:25:05 +0000 Message-ID: References: <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> <83jzw6utnx.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83jzw6utnx.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Jun 14, 2023 at 15:15:14 +0300, Eli Zaretskii wrote: > > Date: Tue, 13 Jun 2023 21:36:37 +0000 > > Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > > 63967@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > > So I see the fix somewhat along the lines of removing the offending > > Fset_frame_selected_window from minibuffer_unwind, and maybe rearranging > > the calls to record_unwind_protect* in read_minibuf to arrange for the > > window configuration call to do the job of restoring the "current" > > window. > > > > It seems to me you might want to put the fix into Emacs 29. Am I right? > Yes. I wouldn't be pinging you if it weren't so. :-) > So I hope you will present a suggested patch soon, and that it will be > simple and safe enough to install on the release branch. TIA. OK, thanks. I should have enough time to look at it properly from this evening (European time). I hope to have a patch ready on Friday, or possibly Saturday. As for "simple and safe enough", we'll see what we can manage. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Jun 2023 11:33:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: al@petrofsky.org, rudalics@gmx.at, acm@muc.de, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168700152631518 (code B ref 63967); Sat, 17 Jun 2023 11:33:03 +0000 Received: (at 63967) by debbugs.gnu.org; 17 Jun 2023 11:32:06 +0000 Received: from localhost ([127.0.0.1]:50960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAUA2-0008CI-9R for submit@debbugs.gnu.org; Sat, 17 Jun 2023 07:32:06 -0400 Received: from mx3.muc.de ([193.149.48.5]:15420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAU9y-0008Bi-Bg for 63967@debbugs.gnu.org; Sat, 17 Jun 2023 07:32:05 -0400 Received: (qmail 95934 invoked by uid 3782); 17 Jun 2023 13:31:55 +0200 Received: from acm.muc.de (p4fe152e6.dip0.t-ipconnect.de [79.225.82.230]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 17 Jun 2023 13:31:55 +0200 Received: (qmail 20481 invoked by uid 1000); 17 Jun 2023 11:31:54 -0000 Date: Sat, 17 Jun 2023 11:31:54 +0000 Message-ID: References: <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> <83jzw6utnx.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83jzw6utnx.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Jun 14, 2023 at 15:15:14 +0300, Eli Zaretskii wrote: > > Date: Tue, 13 Jun 2023 21:36:37 +0000 > > Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > > 63967@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > > So I see the fix somewhat along the lines of removing the offending > > Fset_frame_selected_window from minibuffer_unwind, and maybe rearranging > > the calls to record_unwind_protect* in read_minibuf to arrange for the > > window configuration call to do the job of restoring the "current" > > window. > > > > It seems to me you might want to put the fix into Emacs 29. Am I right? > Yes. I wouldn't be pinging you if it weren't so. > So I hope you will present a suggested patch soon, and that it will be > simple and safe enough to install on the release branch. TIA. After spending quite some time looking at why that call to Fset_frame_selected_window went in in the first place, and checking quite a few of the bug scenarios from 2021, I'm now convinced that the sole fix we need is to remove that call from minibuffer_unwind. It's certainly a simple patch, and I think it's safe enough for Emacs 29. Maybe other people (e.g. Martin) would be good enough to give it a quick going over before we commit it. diff --git a/src/minibuf.c b/src/minibuf.c index d5f95968ae1..bcb7eb9375d 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -1266,9 +1266,6 @@ minibuffer_unwind (void) set_window_buffer (window, Fcar (entry), 0, 0); Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); - /* set-window-configuration may/will have unselected the - mini-window as the selected window. Restore it. */ - Fset_frame_selected_window (exp_MB_frame, window, Qnil); } else set_window_buffer (window, nth_minibuffer (0), 0, 0); -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Jun 2023 13:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie , rudalics@gmx.at Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.16870073319365 (code B ref 63967); Sat, 17 Jun 2023 13:09:02 +0000 Received: (at 63967) by debbugs.gnu.org; 17 Jun 2023 13:08:51 +0000 Received: from localhost ([127.0.0.1]:51026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAVfe-0002Qy-S7 for submit@debbugs.gnu.org; Sat, 17 Jun 2023 09:08:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAVfc-0002Qk-AQ for 63967@debbugs.gnu.org; Sat, 17 Jun 2023 09:08:49 -0400 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 1qAVfU-000080-Ip; Sat, 17 Jun 2023 09:08:40 -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=67WIPnu7SHdptOrIm4omZDmDqs//tDlYOieIgEV7RJU=; b=UQJXb2x6lDF8 ZcxMR4grQJ6Hkv+PyfpNkAUSwcbnYbW4Wix8lb0SAn1dAnDDodB72KWE689FBew4Xky//Ry2TDepI LqAAhHsBgaD0Zkgi8L1aBJgMGvYDYqO9jbsKyHRuQiPZXTYv4ObsQ0Uf4U4flxC4uSffTHHE85miO GKfpaPzRVbB9aBrH1brqKzHZbHPANZfeJId5C6HMbNHuChsSmwse65u6316zTMnvCPPLkUwo/vLS6 Fjygp4CatKb32nUQeHfXRS/EszYkUpn10uPMaY5M+7sNvsBokNs/1XAx6nUj4oCPt05cxgMpIn158 okQ74pYUQoJk10RVbN+clQ==; 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 1qAVfT-00030A-F8; Sat, 17 Jun 2023 09:08:40 -0400 Date: Sat, 17 Jun 2023 16:08:38 +0300 Message-Id: <838rciqlrd.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Mackenzie on Sat, 17 Jun 2023 11:31:54 +0000) References: <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> <83jzw6utnx.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 17 Jun 2023 11:31:54 +0000 > Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, > 63967@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > So I hope you will present a suggested patch soon, and that it will be > > simple and safe enough to install on the release branch. TIA. > > After spending quite some time looking at why that call to > Fset_frame_selected_window went in in the first place, and checking > quite a few of the bug scenarios from 2021, I'm now convinced that the > sole fix we need is to remove that call from minibuffer_unwind. > > It's certainly a simple patch, and I think it's safe enough for Emacs > 29. Maybe other people (e.g. Martin) would be good enough to give it a > quick going over before we commit it. Thanks. Martin, please comment. Your own proposal was similar, so I hope you will agree to this. From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Jun 2023 13:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie , Eli Zaretskii Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168700996114042 (code B ref 63967); Sat, 17 Jun 2023 13:53:01 +0000 Received: (at 63967) by debbugs.gnu.org; 17 Jun 2023 13:52:41 +0000 Received: from localhost ([127.0.0.1]:51076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAWM4-0003eQ-Kd for submit@debbugs.gnu.org; Sat, 17 Jun 2023 09:52:40 -0400 Received: from mout.gmx.net ([212.227.17.20]:45197) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAWLz-0003eA-EZ for 63967@debbugs.gnu.org; Sat, 17 Jun 2023 09:52:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1687009944; x=1687614744; i=rudalics@gmx.at; bh=i9zTeFN8DxNwoVd0DcypFkLlZ0x6GN7ZWm8ehNbRbbI=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=EsejBbsk9f0WeY8HKCJMDr9Pq8lthyyVbP7TWuwIoY/43/EY/HpL+/tDvL2/8LT2v7QccQu M4mpCVwl75X0kEUbdkvyR6BzFeJVKpymNgOJlqzDtuMnIhrBrfvUcQ97GG/uePOG4TcvzbC3i skuUG7DTwngPhZWfImOzc1nsYucm/86WadYb6AUDEjs9jz+dgVj4E8xq4zr84WUXEcO4w3Rbi D7PeyznA2x0xkyqMZvdnxv/TZHi9fRXsf+/mod4umFhU4krZT1JSt2umC5gnIhlMur+aCTUo+ nuE3xHHAlDb0OaU51p/p63zbdNRetGj8Ag9zMtKyG0FbkGDw1t6A== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([213.142.96.140]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MkHMP-1phT4Q386j-00kf3r; Sat, 17 Jun 2023 15:52:23 +0200 Message-ID: <16d7e21b-c70a-f345-58a5-9be8080fed25@gmx.at> Date: Sat, 17 Jun 2023 15:52:22 +0200 MIME-Version: 1.0 Content-Language: en-US References: <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> <83jzw6utnx.fsf@gnu.org> From: martin rudalics In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:9nexe162LoZUuW7FGD015YRdswnU3gfkclSZ0Fr7mdPvGONumGD zLeP7NDijtnt8EssU6MoJHkwX0goI9qyQ/NhL0IJf9Bs5/LXcCeAg9ofxDdc1PXnkIwMmbq iSrY+amXmdkDO9oxw2ZwiKx88DKXZO2FId8V3LZR5GBCSsXS0sbxsxgLrdQ55dDBbaHpf87 heU7quuNKByFAjDH8D52g== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:cte2ghccyvc=;iOTB6N2bw3LYgwrPuIjPs3vVLoT Uiy4Hury2nfoisCZoBMhrT6YA51WUz5rh2sA1wsvRdRKUeZhhYVuWFELmM273wIYXOIbDRsG8 Xixw6cstPR2SCcS169dP7KPyLwzjerk1ihCCbKLpaUsA1u2VwmfRJZTComiB8x1EZwK2pRFzH xbWWhZnNxLoCnUjPZyQful7yjgZguj4WgxcuuJPsig0ujHGb/9x9fX1shVcrLX1NkiOlTsTi6 72WcUYq4v2bptyzdw3G7WLoTuJOkPVjI8v8Vy76kf2CFqKmRWvnYbJpfVPwtRNdVDzx3apy0j 7jKKjdP/De2e8ys/c2iCkBQLpOdT09ald/gb9AILdg42+NloJPLIpUGts1VTda9t2MK2ozPHI mbNqf4VA/gW0qIF12ZF8dphVPjUH6hFMj2ifODVkbi1cDmgugWCmcA+fFymA0dBxt9nrVCVT0 F/+OHk1ZxDdLeZp0gLWNMORmBbefT+KT0cXKYHwboqpnzGgiS24vfcqxazjpePE9hjKjoZXPR QB06Dr0oKMSbHSemRY1jArGWhdzMcN0BuETDm5GKK6eVC8NNaRWDktrUcRBD5AKvOV0oD6np1 c8pk7we+tbnuInGyH4C1NjpY5I71QzSEXpOo6bmMZfi6t5QiDlJOiiMO5hQJqAavequp4udnY rLgsZQYk98p/RSXSGDlcOIlMq+SVGvs2PcmifqwL3kII2AXqxwsoCTcL0rII9lCaTtvdpWMUp f1HOeGNCriQJA0J3F0AgfJXjLhM7eTYy7poIVcoC6hKTzZ2eMT2T9MLO/Ytu3ly+vagATcZJU svhcr7eWuT77aFr5F7JsWTBurCDduKRwNo51SCXZiNbqNlANiI5ErXupORs7S33nQ/FI+AXd8 XXlsHSLGlG5wELdqMJlYO9Evyi7KX/8XQU3DKpmAWViqTpfEe2WpU6KdjxmVl0eC0GJ+Qm1a5 cVEIved786Et7ptXfbZBZcYWbjY= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > It's certainly a simple patch, and I think it's safe enough for Emacs > 29. Maybe other people (e.g. Martin) would be good enough to give it a > quick going over before we commit it. I cannot see any problems with it. martin From unknown Sat Jun 21 12:28:00 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Al Petrofsky Subject: bug#63967: closed (Re: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active) Message-ID: References: X-Gnu-PR-Message: they-closed 63967 X-Gnu-PR-Package: emacs Reply-To: 63967@debbugs.gnu.org Date: Sat, 17 Jun 2023 16:24:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1687019042-4969-1" This is a multi-part message in MIME format... ------------=_1687019042-4969-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #63967: 28.2; switch-to-buffer in normal window fails if minibuffer window = is active which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 63967@debbugs.gnu.org. --=20 63967: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D63967 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1687019042-4969-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 63967-done) by debbugs.gnu.org; 17 Jun 2023 16:23:15 +0000 Received: from localhost ([127.0.0.1]:52501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAYhm-0001Gy-Ra for submit@debbugs.gnu.org; Sat, 17 Jun 2023 12:23:15 -0400 Received: from mx3.muc.de ([193.149.48.5]:23773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAYhk-0001Gh-39 for 63967-done@debbugs.gnu.org; Sat, 17 Jun 2023 12:23:13 -0400 Received: (qmail 33409 invoked by uid 3782); 17 Jun 2023 18:23:05 +0200 Received: from acm.muc.de (p4fe152e6.dip0.t-ipconnect.de [79.225.82.230]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 17 Jun 2023 18:23:05 +0200 Received: (qmail 21889 invoked by uid 1000); 17 Jun 2023 16:23:05 -0000 Date: Sat, 17 Jun 2023 16:23:05 +0000 To: martin rudalics Subject: Re: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Message-ID: References: <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> <83jzw6utnx.fsf@gnu.org> <16d7e21b-c70a-f345-58a5-9be8080fed25@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16d7e21b-c70a-f345-58a5-9be8080fed25@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63967-done Cc: al@petrofsky.org, 63967-done@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Martin and Eli. On Sat, Jun 17, 2023 at 15:52:22 +0200, martin rudalics wrote: > > It's certainly a simple patch, and I think it's safe enough for Emacs > > 29. Maybe other people (e.g. Martin) would be good enough to give it a > > quick going over before we commit it. > I cannot see any problems with it. Thanks, Martin. I've now committed the patch to the emacs-29 branch, and I'm closing the bug with this post. > martin -- Alan Mackenzie (Nuremberg, Germany). ------------=_1687019042-4969-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 9 Jun 2023 04:09:10 +0000 Received: from localhost ([127.0.0.1]:58094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7TR0-0000MF-AC for submit@debbugs.gnu.org; Fri, 09 Jun 2023 00:09:10 -0400 Received: from lists.gnu.org ([209.51.188.17]:51588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7NFo-0006iS-Vt for submit@debbugs.gnu.org; Thu, 08 Jun 2023 17:33:13 -0400 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 1q7NFo-0000qt-P0 for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 17:33:12 -0400 Received: from mail-pl1-f178.google.com ([209.85.214.178]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q7NFn-0001oI-1o for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 17:33:12 -0400 Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1b02fddb908so1324265ad.1 for ; Thu, 08 Jun 2023 14:33:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686259989; x=1688851989; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UXZk86RCRrvdKHdHfSSHnAJfG+IgU4uq6voWSBQl6E4=; b=E7j7i7hqemQ9qHUYZAl5tF3UJHWxpRsBh/KFXcRJ7VMZima1Zx/q7GnLwsqKIookSn +8Ilws4tUnov9aAieiMFdHVaPAJDwNBfuezCSs+iVkIZbS1qmQ2x/7ngzjlLa5MOG7Va zz4oDu9bL/0pSF06FRPW8owlXKyFlqAzxiLqdz20g7GICu4ODQEAcM0fEpLP6mBHRtba vjvq+nIrNyCXeLbQeuM1VegqSQgjp+c/1AeOA/g41PbaB/nEvpdO4sJT8e0dJZLtsY/c psBoqoA+eSxnmq5RQjXFqXenW9KPwF4RZ7wK9G/ANOqaKjxZLYFELd4VHHqsW6h/u1VC i0Gg== X-Gm-Message-State: AC+VfDx+gaxsi+P3xwkllekCyMgpDq3ZV1BkS4PqyuEe9CKbWeGI8Rt8 uuUHATciNDX5siWfXYie+mNz5fpDHQR7KA4Kpyh2kN+badU= X-Google-Smtp-Source: ACHHUZ5xSqDNjiFaMQQV8pueXg9KevbB93a4cfWbYuAzr73kWSWn6yQpTMTEoCPZDAj8FeFZfxoWGqnh9GCUIkI7RtM= X-Received: by 2002:a17:902:d482:b0:1b1:f194:ebb1 with SMTP id c2-20020a170902d48200b001b1f194ebb1mr10539061plg.0.1686259988665; Thu, 08 Jun 2023 14:33:08 -0700 (PDT) MIME-Version: 1.0 From: Al Petrofsky Date: Thu, 8 Jun 2023 17:32:56 -0400 Message-ID: Subject: 28.2; switch-to-buffer in normal window fails if minibuffer window is active To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="0000000000009f999905fda4ffaa" Received-SPF: pass client-ip=209.85.214.178; envelope-from=al.petrofsky@gmail.com; helo=mail-pl1-f178.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 09 Jun 2023 00:09:05 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --0000000000009f999905fda4ffaa Content-Type: text/plain; charset="UTF-8" While the minibuffer window is active, attempt to switch buffers in an ordinary window like so: emacs -Q M-: (setq enable-recursive-minibuffers t) RET M-x C-x o C-x b foo RET In emacs 27 and earlier, that will switch the buffer in the main window to the new buffer named "foo", but in emacs 28.2, it generates a bogus "user-error: Cannot switch buffers in minibuffer window". I get the same results with -nw. --0000000000009f999905fda4ffaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While the minibuffer window is active, attempt to swi= tch buffers in
an ordinary window like so:

emacs -Q
M-: (setq = enable-recursive-minibuffers t) RET
M-x C-x o C-x b foo RET

In em= acs 27 and earlier, that will switch the buffer in the main
window to th= e new buffer named "foo", but in emacs 28.2, it generates
a bo= gus "user-error: Cannot switch buffers in minibuffer window".
=
I get the same results with -nw.

--0000000000009f999905fda4ffaa-- ------------=_1687019042-4969-1-- From unknown Sat Jun 21 12:28:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Jun 2023 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: al@petrofsky.org, rudalics@gmx.at, Eli Zaretskii , 63967@debbugs.gnu.org Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168702759919946 (code B ref 63967); Sat, 17 Jun 2023 18:47:02 +0000 Received: (at 63967) by debbugs.gnu.org; 17 Jun 2023 18:46:39 +0000 Received: from localhost ([127.0.0.1]:52629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAawY-0005Be-Iq for submit@debbugs.gnu.org; Sat, 17 Jun 2023 14:46:38 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAawW-0005BS-LS for 63967@debbugs.gnu.org; Sat, 17 Jun 2023 14:46:37 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 62B901001FC; Sat, 17 Jun 2023 14:46:31 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7B030100083; Sat, 17 Jun 2023 14:46:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1687027590; bh=ArkaDYJvZJBaqL/SKjTaoUyNooEzQqjSf+uWRmRMtyA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ilB0bB3il2Hxv1lYzYmqXlwZQ9N4d/QGb4JW4fn+Ky0TiJExp0Y18FDWblNhIAVma tIUohX0etbpTCExY0Q/m6FD4O0FJmT4REJUv2O2Quhv72TdkywnPK28FfARSRCtr6k NgqzTu42BYwD++45GNS5s5k4iF6zuSayZ71y2Bjc5FHo+bzRLicst/0vvfPoAYAJ+u 9PYnv4cuAvlFNskaHH7NJu4xL1w7jVkKnbrXkX63CTs9933RoTMEzmUxebdHSd2Js/ s9JwWMX41//f9L+sqALle8vuxqRx4aukYPBzO0njtLBkkZpY/zu1VsI12jueyPamb+ I7oZ4GUDyCLUw== Received: from pastel (unknown [45.72.207.87]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4671E120796; Sat, 17 Jun 2023 14:46:30 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Alan Mackenzie's message of "Sat, 17 Jun 2023 11:31:54 +0000") Message-ID: References: <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> <83zg56xfyr.fsf@gnu.org> <83v8frursu.fsf@gnu.org> <83jzw6utnx.fsf@gnu.org> Date: Sat, 17 Jun 2023 14:46:28 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.170 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > After spending quite some time looking at why that call to > Fset_frame_selected_window went in in the first place, and checking > quite a few of the bug scenarios from 2021, I'm now convinced that the > sole fix we need is to remove that call from minibuffer_unwind. That was my intuition, but I wasn't confident enough in my understanding of the code to suggest it :-) Stefan