From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: About the 'minibuffer' frame parameter Date: Sat, 06 Aug 2016 11:32:45 +0200 Message-ID: <57A5AEBD.9040805@gmx.at> References: <579E3F9E.8020200@gmx.at> <83h9azl4s1.fsf@gnu.org> <57A4C0DE.3060506@gmx.at> <9605148d-fa81-4cbc-ae81-9e1e8bd11362@default> <57A4CE4C.5010901@gmx.at> <57A4D8C3.5030205@gmx.at> <3e5c74c4-40ae-4b6e-8e8e-444306abb189@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1470476029 20725 195.159.176.226 (6 Aug 2016 09:33:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2016 09:33:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 11:33:45 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bVxz9-0004DO-Qn for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 11:33:40 +0200 Original-Received: from localhost ([::1]:48615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVxz6-0001P3-KD for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 05:33:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVxyZ-0001ON-KT for emacs-devel@gnu.org; Sat, 06 Aug 2016 05:33:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bVxyY-0007vh-Bf for emacs-devel@gnu.org; Sat, 06 Aug 2016 05:33:03 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:60977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVxyT-0007v6-6o; Sat, 06 Aug 2016 05:32:57 -0400 Original-Received: from [192.168.1.100] ([212.95.7.63]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lev1D-1atZhV3HAd-00qmGD; Sat, 06 Aug 2016 11:32:50 +0200 In-Reply-To: <3e5c74c4-40ae-4b6e-8e8e-444306abb189@default> X-Provags-ID: V03:K0:+XN2XELFFzWpGWg2/RvBJzqXeQMvmc8SQZ3roLx/xq7Y35+6wEL gJZGSCDuCYBQWGwN7AsFp/rQabxW6/i2a0pycR28v3EgQM7K5iz/ngV5fbCKlS06GpmSBxZ vre6wyRfzv8U7WklcVaj9fl6EATSpWEO9pqURybmrnHpQLGXb1we3jK5qfLV4EGOUXbWbwD ubNUoijzF2GTpqwOUdNZg== X-UI-Out-Filterresults: notjunk:1;V01:K0:GlYF0hQnYgk=:AgPANu32HtWjygURBa2gBk ti8bGRk/S722HATejf7lFrjztpx9f3G8JhfJcQ5hQOdPjpeMMt4JxVt3wqOLmuHc9QnOFmWhl SKLCK4a5I7O7RFebQ7cXUGHAYUSW8ot5z5XFbSkcY13sIIGa5YWDFfZBoqjZ2lzRMB6I8tYLP swS9dHknuafV8HoDn+zI1LwMrZr0z79et3os/SRXbQz/Af103PWH14KEUXpwJHkypBQatcscl OAnrNIC1L8lwcK2nhu+krWjk6VAFGnmKJSi7t7Tce043zZw39NJz//IckUJQcYW1amHSglXRP e2FL7LyxyCktzXnqgXpIjq4k16FXZx/ZAzriLxo4Qy0kqDkD1Ua4xfu/8sFc6C74LlkavZqYa GALjSaBGvr4o++A5E7bV0f9TWPD5Tiby2YFUfLbdQ5Godd2Jb5bgXC4vE68ZAKYOZrTrnUbZV g7yceVPLal9wbLBeVCIWGI1gH2ZGPFKsfrMbiIbqe3aelsGIfy+nmBypuMNFm3ad8gcdKYPSc KIxMfqfokNOMGFIFwHDnKeC7r9OlLEN3VcLEGVzQk3Vd9U/NzCI+9ejBP88XCAyFAjasqaz0l jTsIDXjKwf067TuN6gFQKdGQi/CDK65l8Bw55eV7O/9INNs8UwN6lauKbv1yTWh7JBALckEUE wGiDiYdggSdvGE04rTAfhb7iBEXKYxdEDKRvys/dbMI0oSSv4YNUWMleWrqRfzVTksMbi+8Gt dlFKKHWmLzBH4lNaK4hQqgb925/idehNdSbf9gCzvQFkK68A+u9D6I3ToWCb0mjNc9mYjrhS X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206435 Archived-At: > They are not clear to me, even on re-reading. Sorry for being unclear. Let me try once more: With emacs -Q, yank the following forms into *scratch* (defvar initial-frame (selected-frame)) (defvar minibuffer-less-frame (make-frame '((minibuffer . nil)))) (defvar minibuffer-only-frame (make-frame '((minibuffer . only)))) and evaluate them. You should see three frames - the "normal" initial one, a minibuffer-less frame, and a minibuffer-only one. Correct? Now in the minibuffer-less frame evaluate (frame-parameter minibuffer-less-frame 'minibuffer) and Emacs will print nil in the minibuffer window of the initial frame. Next evaluate (set-frame-parameter minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-fr= ame)) and you will see nil in the minibuffer window of the minibuffer-only frame. Now evaluate (set-frame-parameter minibuffer-less-frame 'minibuffer (minibuffer-window initial-frame)) and you will see nil in the minibuffer window of the initial frame again. From this we can conclude the following: (1) Emacs does redirect output to the minibuffer window of the frame specified via =E2=80=98set-frame-parameter=E2=80=99. This follows f= rom the experiment above because you see the value reported by =E2=80=98frame-parameter=E2=80=99 appear in different minibuffer win= dows. (2) Any such redirection is not reflected in the 'minibuffer' value reported by =E2=80=98frame-parameter=E2=80=99: That value remains ni= l invariably. Do you agree so far? Then I see the following problems. From (2) the 'minibuffer' value assigned by =E2=80=98set-frame-parameter= =E2=80=99 is not reflected in the 'minibuffer' value returned by =E2=80=98frame-parameter=E2= =80=99. This is not critical per se (a similar thing may happen to geometry parameters) but it's misleading because, as we can conclude from (1), something has changed. Moreover in section 28.4.3.5 Buffer Parameters of the Elisp manual we say: `minibuffer' Whether this frame has its own minibuffer. The value `t' means yes, `nil' means no, `only' means this frame is just a minibuffer. If the value is a minibuffer window (in some other frame), the frame uses that minibuffer. This frame parameter takes effect when the frame is created, and can not be changed afterwards. But apparently it is possible to change the 'minibuffer' frame parameter after a frame was created since otherwise we were not able to redirect output as mentioned in (1). Regardless of whatever =E2=80=98frame-parameter=E2=80=99 reports, the val= ue of the frame parameter stored by Emacs internally is the window specified by (frame-root-window minibuffer-only-frame). The routine constructing the =E2=80=98frame-parameters=E2=80=99 alist replaces the real internal value= by the value nil. Finally evaluate the form (frame-parameter initial-frame 'minibuffer) You will see something like # appear in the minibuffer window. This is a window on the initial frame. =E2=80=98frame-parameter=E2=80=99 returns a minibuffer window if and only= if that minibuffer window is on the _same_ frame as the one whose minibuffer value I try to retrieve. You can't convince =E2=80=98frame-parameter=E2=80= =99 to report a minibuffer window "in some other frame" as the manual suggests. Am I still unclear? >> Because IIUC they do not care much about "testing" it. Otherwise the= y >> would have complained already. > > What is the problem with testing it? That the "reported" value does not reflect the "set" value as described above. > frameset.el tests it. And I test it. I `redirect-frame-focus' of a > minibuffer-less frame for *Completions* to my standalone minibuffer > frame, for example: [...] > Okay, I don't actually test the frame parameter here explicitly, but > the code depends on it being and acting as it does, I think. I don't think so. You just use the return value of =E2=80=98make-frame=E2= =80=99 invoked with a (minibuffer . only) parameter. Alternatively, you might use (window-frame (minibuffer-window my-minibuffer-less-frame)) In general, =E2=80=98frame-parameter=E2=80=99 is useless for finding the = minibuffer frame. As long as nobody works with the return value of =E2=80=98frame-parameter= =E2=80=99 there are no problems. On the C-level code works with the "real" value of the parameter as set by =E2=80=98set-frame-parameter=E2=80=99 and does not ha= ve the problems I mentioned here. Actually, C-code never even consults that value - it only sets it. martin