From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: What is restore_window_configuration in read_minibuf (minibuf.c) for? Date: Mon, 19 Apr 2021 11:31:22 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5239"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: martin rudalics , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 19 17:33:45 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 1lYVuC-0001Cg-5Z for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Apr 2021 17:33:44 +0200 Original-Received: from localhost ([::1]:44468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYVuB-0007S5-61 for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Apr 2021 11:33:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54724) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYVs0-0006Uh-JL for emacs-devel@gnu.org; Mon, 19 Apr 2021 11:31:28 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5599) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYVry-0000LY-69 for emacs-devel@gnu.org; Mon, 19 Apr 2021 11:31:27 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CC8448078F; Mon, 19 Apr 2021 11:31:24 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5FF6280810; Mon, 19 Apr 2021 11:31:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618846283; bh=EBQf2phYXWym0r9k9mqlTB875pqloDlcR1VhxHGBri4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=XAT5aSnFw+YDGrgGutai411U6cMFc4xHczCvujdnip6gv842ZZ9gtdrp+wWWU5vec u1PhsYVyPKF4FajsV3Rf5+skVm3bpC0nnRTG39VIhm7oNs1pC0/3nwThmylh2KYnk7 neZCGvOuU+7cPw1hxWK9LylL3zjZWbxC8zJmsHszUbXdeMWQY3gzq4gH3a3k6Y5jkU aGMJWIMNLvlNHzDOaGHNFx453BB0HQYkRCYZoQt6/ATuQ+mA8jaktYQGucQmztQEgM Pgn+BhiXbYLKP9NwrUDlPvwl3K2ZSN4qB2rQgeqSE8gZlZpYopLfkFBbs9V5TjTDbR VfLasGje+P6vw== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2A0D012019A; Mon, 19 Apr 2021 11:31:23 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Mon, 19 Apr 2021 14:56:29 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:268174 Archived-At: > 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. Indeed. I think we should remove it, but for that we need to replace it with something that does the part we want to keep (e.g. making sure that the buffer from which the minibuffer was "called" is selected&visible again). > 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? Maybe the restoration of some previous minibuffer is OK (e.g. when you use `M-x` from within `M-:` you do want the outer minibuffer to be restored when you leave the inner one), and you just need to adjust it after the fact in the rare cases where it results in an undesirable state (e.g. if that minibuffer was already displayed elsewhere). Stefan