From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Mon, 4 Jan 2021 10:20:11 +0100 Message-ID: <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> References: <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32488"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Gregory Heytings , Eli Zaretskii To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 10:21:54 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 1kwM3l-0008KT-RZ for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 10:21:53 +0100 Original-Received: from localhost ([::1]:43158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwM3k-0003rS-TO for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 04:21:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwM2Y-0003P6-F3 for emacs-devel@gnu.org; Mon, 04 Jan 2021 04:20:38 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:38683) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwM2W-0003Gm-5c; Mon, 04 Jan 2021 04:20:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609752018; bh=KcshQqP2unM3HGzebHwY18mQ6Xx3Mix+pFplZ7o4Inc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=WEnnFTTsaucfFh3nN2KVaIoFHug2VetNBfQ6bYZBaXddkDnj75U6J7EomPeUS5MDH WszGss8q9EieAZqgvchT72jAe9X42W7WDt5CEv1dDq9OuVETQzXBrK7OR2kpa3wZ/P 5Xr0AO6ce/G6jQ1zyAoB5hCbVu+Qfp9jYkY4OKS8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.239]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0oBx-1k2Irs3aYX-00woEd; Mon, 04 Jan 2021 10:20:17 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:9JKHrYUd0yjnNBQYA5T4Tx6uKDToKdvWf9YZIwT9PSUVg3QBYGC H+w/QElLj2o/m+aV/C99VACWDM27ib/I5F343Lxl+7Q9PqVlMvzR3Cq2huHi93yktYFEsFo nbbfvwWJEQE4DuH1vcMToBoBuY9i+kAGDv/eWsjf2cmdJC/XHCa8j9zt40RV7fp/JD9W1eL rSkM6uKlsZ1THc5XBeKtA== X-UI-Out-Filterresults: notjunk:1;V03:K0:XUWNULuLzhA=:VCE+aV8pOQAOfCJ2VEY9Vy cX1B2U9w0ynbWpSTRLUw4OzSmzPSS6IyxCmqJJltO61kBRFG2XoDWQcl2YN2FiMEvM9kL1ciD 9KWCy+5XRwEIMG49uOxAEjkYg+bFkPeO/qo+YmM+xTR6V28Xj/9zlgq0PmIH/GB1OlEOQSGYI pITC8Xb3XhdaUiuPfkSjahevZpWgsSDMZOGJCdUmE3QC9ZmmAlsNIZ4Pq+zYUau1/O70vMgGl wJ6CXJcfoKHz/PKz2OI8hlVhFNyHNzsvvrXYlwYkETm1E+4t6crbLXXSA9qd0X4VUfjs5Tf+y shWQJMf27lAH4998HPcRbNjMdokU8Ksde2OBPpHP8MFMB22oi5VmOJxqyS0bdD977+yW1fmXM CaU9FBH7pzBzBW4e3Dqc2lJxhfgJj89QoEEd3F3qZuE5XtUPKxMcw5OlgSXfT+Bb30Q0KolSI TUFDEYUcfDEqtH64goIcgs/PfGG7+MRpxXVZBm6/JXuUGAtbDHV+hRP7vcGv5vF1tW6lxywnd KhjSI1JssdiFizAYajZLbcCWd7rATBP5ZK98/KfAr9HxS9w3Aoo21tTUdhAch6uZKt5Zi8HOc saZD5QMUPvDq/ybIozXX0FbkMJPQ5kH/ll0+e79PChhEUZilOvaJ1ONKA7krc8/VOuYdxrrPj 9y9LGs/RknHRSTub3K6CiKw95pZ1cmN7xy3Wdny09eANo+7ybVf+gGZQowyZTl+DQ8NvfX8rd e7CPyqi0KTOngTkx0uf9/jG028GblHibMD9q+zUm4vbdA5/R7OOwKVl54mIFOzdkVn2mUZa/ Received-SPF: pass client-ip=212.227.17.21; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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:262403 Archived-At: It builds now so let's get back to your initial request. > 1/- "Madhu's bug". Set pop-up-frames to 'graphic-only, do M-!, type > g TAB, which opens *Completions* in a new frame. Select something. The > *Completions* frame should be deleted, but isn't. > > This was a problem in window-deleteable-p (window.el), where if an > active minibuffer is in a frame, that frame is regarded as not to be > deleted. The new minibuffer mechanisms move minibuffers to the new > frame on a frame change, so this obviously(?) clashed. I have amended > window-deleteable-p to take account of > minibuffer-follows-selected-frame and the new mechanisms. I leave this to Madhu. Here the minibuffer frame is not deleted but gets iconified which is probably due to the default of 'auto-hide-function', something I'm not going to dispute here. > 2/- From Martin: Start emacs -Q -l foo.el, where foo.el is: > > (setq default-frame-alist '((minibuffer . nil))) > > (defun foo () > (interactive) > (read-from-minibuffer "...?") > (insert (format "%s" (selected-frame)))) > > (global-set-key [(control meta +)] 'foo) > > (setq enable-recursive-minibuffers t) > > Do C-M-+, type something into the minibuffer, and either selected-frame > announced *Minibuffer-1*, or there was an error about "Window not being > in Frame". Both of these problems are now fixed. Confirmed. At least I can't reproduce them any more. > > 3/- From Gregory: Start emacs -Q, and set enable-recursive-minibuffers > to t. Do C-x C-f C-x 5 o twice, then C-x C-f a third time. It was > possible to enter filenames for and visit files for the innermost two > minibuffers, but not the outermost one. This has (I believe) been > fixed. I'm not sure what's missing here, probably a C-x 5 2 to get the frame C-x 5 o can act upon. So I let Gregory tell whether this has been fixed. What I see is that with 'enable-recursive-minibuffers' t C-x 5 2 followed by two C-x C-f C-x 5 o - doesn't get me _always_ into the minibuffer window of the frame switched too (I'm not sure whether it should and under which circumstances - this should be clarified), and - typing C-g to quit an inner invocation of C-x C-f sometimes gets me a catatonic minibuffer window where either nothing is displayed or just a simple "Quit" appears - I have to get out of it via C-x o. > 4/- With minibuffer-follows-selected-frame nil, and > enable-recursive-minibuffers t, there were problems caused by editing > outer level minibuffers whilst an inner level buffer was still active. > I've tried to fix this by giving outer level MBs the keymap > minibuffer-inactive-mode-map temporariliy whilst a recursive MB is > active. How do I edit an outer level minibuffer whilst an inner level buffer is active? > One bug which I haven't fixed, and doesn't appear to be to do with these > changes, is: > > > 5/- emacs -Q, enter the following into *Scratch*: > > (defun bar () > (interactive) > (read-from-minibuffer "...?") > (insert "window: %s ... frame: %s" ... which is probably missing a "format" here ... > (selected-window) (selected-frame))) > > , evaluate it, then evaluate (bar). The window announced under "window:" > is *Scratch*, that under "frame:" is *Minibuf-1*. It seems they should > match. > > I think the problem is that frame->name doesn't get appear to get set on > a set-frame-selected-window call. I think the command loop sets > frame->name, and the recursive command loop in read_minibuf sets it to > *Minibuf-1*, and nothing else changes it until the next iteration of the > main command loop. > > Also, this bug was in the version of master just before I made my first > commit in this area. That's probably part of the select window/frame mystery. You just can't have them both - 'select-window' and 'select-frame' - and hope that they will live happily ever after. Maybe a wset_redisplay (XWINDOW (window)); after the fset_selected_window (XFRAME (frame), window); is due so that the redisplay mechanism knows what title to draw in that frame but I don't think we should care much. martin