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: Re: What is restore_window_configuration in read_minibuf (minibuf.c) for? Date: Mon, 19 Apr 2021 14:56:29 +0000 Message-ID: References: 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="28987"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 19 17:05:29 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 1lYVSp-0007QD-5T for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Apr 2021 17:05:27 +0200 Original-Received: from localhost ([::1]:50760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYVSo-0007RX-4P for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Apr 2021 11:05:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45106) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYVKK-0005WA-Gw for emacs-devel@gnu.org; Mon, 19 Apr 2021 10:56:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:31995 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lYVKD-00081W-Me for emacs-devel@gnu.org; Mon, 19 Apr 2021 10:56:40 -0400 Original-Received: (qmail 31142 invoked by uid 3782); 19 Apr 2021 14:56:29 -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 16:56:29 +0200 Original-Received: (qmail 7378 invoked by uid 1000); 19 Apr 2021 14:56:29 -0000 Content-Disposition: inline In-Reply-To: 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:268172 Archived-At: Hello, Martin. On Mon, Apr 19, 2021 at 14:08:38 +0200, martin rudalics wrote: > > In src/minibuf.c, function read_minibuf, there's a > > restore_window_configuration set up to be called on minibuffer > > termination. > [...] > > 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. > See > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45072 Whew! That's a long thread. The impression I get is that the restore_window_configuration is a user facility, and we can't just remove it, much though I'd like to. > the option I proposed in that thread and Juri's remarks at its end. Juri's remarks from the end of that thread. Thanks for drawing my attention to them: >> It seems that problem is that read_minibuf messes up the windows so >> much, that at the end currently the only way to fix this mess is by >> restoring the previous window configuration. So we can't just remove it. >> This means that there is a need to fix read_minibuf to restore all >> previous window states without using restore_window_configuration. >> Only then it will be possible to add a user option to disable using >> restore_window_configuration. I don't think it is read_minibuf itself that is causing the problems; rather it is the commands used in read_minibuf's recursive edit. That will mean fixing a large part of lisp/minibuffer.el and possibly the latter part of src/minibuf.c. That will be quite a lot of work. Anyhow, back to my bug: It is not restore_window_configuration as a whole which is bugging the mini-windows, it is specifically restoring the mini-window itself to an out of date state. So what seems needed is an extra &optional parameter to set-window-configuration, DONT-SET-MINIWINDOW which would inhibit the restoration of the mini-window. The call from unwinding a minibuffer would pass a non-nil value for this argument. Messy, but I haven't got any better ideas. What do you think? > martin -- Alan Mackenzie (Nuremberg, Germany).