From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: What is restore_window_configuration in read_minibuf (minibuf.c) for? Date: Mon, 19 Apr 2021 10:46:11 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33185"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 19 12:58:34 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lYRbt-0008WX-FE for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Apr 2021 12:58:33 +0200 Original-Received: from localhost ([::1]:58648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYRbs-0002Sj-FR for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Apr 2021 06:58:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYRQ7-0006YF-9o for emacs-devel@gnu.org; Mon, 19 Apr 2021 06:46:25 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:60744 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lYRQ1-0006dO-J9 for emacs-devel@gnu.org; Mon, 19 Apr 2021 06:46:23 -0400 Original-Received: (qmail 51541 invoked by uid 3782); 19 Apr 2021 10:46:12 -0000 Original-Received: from acm.muc.de (p4fe15b44.dip0.t-ipconnect.de [79.225.91.68]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 19 Apr 2021 12:46:11 +0200 Original-Received: (qmail 5544 invoked by uid 1000); 19 Apr 2021 10:46:11 -0000 Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268156 Archived-At: Hello, Emacs. Emacs 28, master branch. In src/minibuf.c, function read_minibuf, there's a restore_window_configuration set up to be called on minibuffer termination. When this call of restore_window_configuration happens, the restored frame sometimes includes a minibuffer which has since moved to another frame (reproduction recipe below). Having the minibuffer displayed on two frames causes trouble. What is the purpose of this restore_window_configuration in read_minibuf? Does anybody know? Removing it appears to fix the above bug, but what problems might this cause? I would like to remove it. Recipe to reproduce the bug: (i) emacs -Q --eval "(setq enable-recursive-minibuffers t minibuffer-follows-selected-frame 'hybrid)" (ii) C-x 5 2, giving two frames F1, F2. (iii) With four existing files file1, file2, file3, file4: (iv) In F1, C-x C-f file1. In F2 C-x C-f file2. In F1 C-x C-f file3. In F2 C-x C-f file4. (v) Currently the minibuffers are stacked up in F2. (vi) In F2 type RET, visiting file4. The MB for file3 is visible in F2's mini window. (vii) In F2's mini window, type RET. This visits file3 in F1, leaving the stack of minibuffers in F2. However .... (viii) The minibuffer for file2 is also visible in F1. This is a bug (see above). (ix) Typing RET in F1's mini window visits file2, but "loses" the minibuffer for file1, which now needs to be aborted with C-]. Just as a matter of interest, the above sequence on Emacs-27 doesn't even get that far - it "loses" the minibuffers for file2 and file1 at an early stage. -- Alan Mackenzie (Nuremberg, Germany).