From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: About the 'minibuffer' frame parameter Date: Sat, 6 Aug 2016 09:46:12 -0700 (PDT) Message-ID: <4522903e-6891-46f7-9838-fca2e481ac89@default> 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> <57A5AEBD.9040805@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1470502094 26093 195.159.176.226 (6 Aug 2016 16:48:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2016 16:48:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 18:48:10 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 1bW4k8-00037w-LF for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 18:46:36 +0200 Original-Received: from localhost ([::1]:50013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW4k2-000207-Er for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 12:46:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW4jw-0001zz-8y for emacs-devel@gnu.org; Sat, 06 Aug 2016 12:46:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bW4jv-0005NF-09 for emacs-devel@gnu.org; Sat, 06 Aug 2016 12:46:24 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:34989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW4jq-0005Mf-Ra; Sat, 06 Aug 2016 12:46:19 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u76GkDu7011723 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Aug 2016 16:46:14 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u76GkDIl005290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Aug 2016 16:46:13 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u76GkCGo003396; Sat, 6 Aug 2016 16:46:13 GMT In-Reply-To: <57A5AEBD.9040805@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:206452 Archived-At: > 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? Yes. > 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. Yes. > Next evaluate > (set-frame-parameter minibuffer-less-frame 'minibuffer > (frame-root-window minibuffer-only-frame)) > and you will see nil in the minibuffer window of the > minibuffer-only frame. Yes. > 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. Yes. > From this we can conclude the following: >=20 > (1) Emacs does redirect output to the minibuffer window of the frame > specified via =E2=80=98set-frame-parameter=E2=80=99. This follows fr= om the > experiment above because you see the value reported by > =E2=80=98frame-parameter=E2=80=99 appear in different minibuffer wind= ows. Yes. > (2) Any such redirection is not reflected in the 'minibuffer' value > reported by =E2=80=98frame-parameter=E2=80=99: That value remains nil= invariably. >=20 > Do you agree so far? Yes... Or maybe not. Doesn't that conclusion depend on supposing that `set-frame-parameter' returns the new parameter value? I don't see the return value of that function mentioned in its doc string or in the manual. (Maybe it should be?) But anyway, if you're sure that the value of `frame-parameter' is nil (I assume you checked this in the C code), then OK. > Then I see the following problems. >=20 > 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. Yes, it is misleading. But why is it not critical (a problem)? And why does it happen also for geometry parameters? (And why does it happen for `frame-parameter'?) > Moreover in section 28.4.3.5 Buffer Parameters of the Elisp > manual we say: >=20 > `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. >=20 > This frame parameter takes effect when the frame is created, and > can not be changed afterwards. ^^^^^^^ cannot (typo) =20 > 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). Yes. And why not be able to do that? And if there is a good reason not to, then maybe Emacs should be fixed to not do it (?). > 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. Hm. > Finally evaluate the form > (frame-parameter initial-frame 'minibuffer) > You will see something like # Yes. > 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. >=20 > Am I still unclear? No. > >> Because IIUC they do not care much about "testing" it. > >> Otherwise they would have complained already. > > What is the problem with testing it? >=20 > That the "reported" value does not reflect the "set" value as > described above. >=20 > > 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. >=20 > 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)) Yes. I don't test it with `frame-parameter'. And I understand that what you are saying is that it is only the value of `frame-parameter' that is useless. But `frameset.el' does test it, AFAICT. Take a look at `frameset--record-minibuffer-relationships', for example. Perhaps there is a bug lurking there (?). > In general, =E2=80=98frame-parameter=E2=80=99 is useless for finding the= =20 > minibuffer frame. If that is the correct behavior then it should be doc'd. Is it the correct behavior? > 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. It seems that Lisp code generally does likewise: set it but not test it. The `frameset.el' code does seem to test it, however. Thanks for explaining.