From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Date: Sun, 11 Jun 2023 16:53:48 +0300 Message-ID: <83zg56xfyr.fsf@gnu.org> References: <83o7lo28e6.fsf@gnu.org> <83fs701uts.fsf@gnu.org> <83a5x81m33.fsf@gnu.org> <83a5x6zj38.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30420"; mail-complaints-to="usenet@ciao.gmane.io" Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 11 15:54:39 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q8LWh-0007j7-6q for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Jun 2023 15:54:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q8LW9-0004Yf-LQ; Sun, 11 Jun 2023 09:54:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8LW7-0004Y7-AB for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 09:54:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q8LW7-0002sd-1i for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 09:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q8LW6-0003ts-G3 for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2023 09:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jun 2023 13:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs Original-Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168649162614970 (code B ref 63967); Sun, 11 Jun 2023 13:54:02 +0000 Original-Received: (at 63967) by debbugs.gnu.org; 11 Jun 2023 13:53:46 +0000 Original-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 Original-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 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 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==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8LVf-0003xb-EO; Sun, 11 Jun 2023 09:53:35 -0400 In-Reply-To: (message from Alan Mackenzie on Sun, 11 Jun 2023 13:40:52 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263247 Archived-At: > 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.