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: Stop frames stealing eachothers' minibuffers! Date: Fri, 20 Nov 2020 21:00:05 +0000 Message-ID: <20201120210005.GA1034@ACM> References: <20201119104035.GB6259@ACM> <9aacff47-8ac2-93a2-5112-6153ee986b57@gmx.at> 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="32639"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, Eli Zaretskii , Stefan Monnier , Andrii Kolomoiets , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 20 22:01:11 2020 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 1kgDWo-0008Nr-8R for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Nov 2020 22:01:10 +0100 Original-Received: from localhost ([::1]:36384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgDWn-0001hh-BT for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Nov 2020 16:01:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40198) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgDVv-00019D-GV for emacs-devel@gnu.org; Fri, 20 Nov 2020 16:00:15 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:21827 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kgDVt-0000ES-9J for emacs-devel@gnu.org; Fri, 20 Nov 2020 16:00:15 -0500 Original-Received: (qmail 31491 invoked by uid 3782); 20 Nov 2020 21:00:08 -0000 Original-Received: from acm.muc.de (p4fe15703.dip0.t-ipconnect.de [79.225.87.3]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Fri, 20 Nov 2020 22:00:07 +0100 Original-Received: (qmail 1823 invoked by uid 1000); 20 Nov 2020 21:00:05 -0000 Content-Disposition: inline In-Reply-To: <9aacff47-8ac2-93a2-5112-6153ee986b57@gmx.at> X-Delivery-Agent: TMDA/1.1.12 (Macallan) 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:259503 Archived-At: Hello, Martin. On Fri, Nov 20, 2020 at 19:47:28 +0100, martin rudalics wrote: > > I've just committed a fix to the Emacs master branch. > Sorry, but this cannot be possibly right. With emacs -Q load a file > with > (setq default-frame-alist '((minibuffer . nil))) > (defun foo () > (interactive) > (read-from-minibuffer "...?") > (insert (format "%s" (selected-frame)))) > insert (foo) into *scratch* and type C-x C-e. After answering the > prompt this gets me #. Do the same with > Emacs 27 and it will get you the *scratch* frame. Yes, I see this (except for the Emacs 27 bit which I haven't tried, yet). However, if I type (frame-list) into *scratch* and do C-x C-e I get only one frame in the list, and it has the same address in the # output as the " *Minibuf-1* 0xxxx" output. In other words, I think your (insert (format "%s" (selected-frame))) is getting the correct frame, but the current buffer within it is still the minibuffer. Might you possibly have simplified the recipe so much that the problem is no longer shown by the recipe? Removing the setting of default-frame-alist from the file doesn't seem to make any difference. > As soon as 'read-from-minibuffer' has finished its job, it is as if it > never happened and the old configuration must have been restored. We > might be able to stay on old_frame when minibuf_level > 0 but in the > scenario above the frame that was selected when 'read-from-minibuffer' > was called must be re-selected. Why were we selecting a frame as an "incidental" side effect of restoring a window configuration? Surely the frame to be selected should be selected deliberately and explicitly. I'm thinking that what needs restoring is the frame's current buffer, and I'm wondering why that wasn't done by the (set-window-configuration foo t) which happened near the end of read_minibuf. > martin -- Alan Mackenzie (Nuremberg, Germany).