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: Mon, 08 Aug 2016 10:27:02 +0200 Message-ID: <57A84256.8030706@gmx.at> References: <579E3F9E.8020200@gmx.at> <83h9azl4s1.fsf@gnu.org> <57A4C0DE.3060506@gmx.at> <837fbvkofs.fsf@gnu.org> <57A5AF03.30807@gmx.at> <8360rck7kd.fsf@gnu.org> 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 1470644887 28336 195.159.176.226 (8 Aug 2016 08:28:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2016 08:28:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 08 10:28:03 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 1bWfui-0006BN-0K for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2016 10:28:00 +0200 Original-Received: from localhost ([::1]:55623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWfue-0004km-Sg for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2016 04:27:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWfu4-0004ka-T4 for emacs-devel@gnu.org; Mon, 08 Aug 2016 04:27:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWfty-0000vd-6s for emacs-devel@gnu.org; Mon, 08 Aug 2016 04:27:19 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:61271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWftu-0000to-07; Mon, 08 Aug 2016 04:27:10 -0400 Original-Received: from [192.168.1.100] ([212.95.7.86]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lj61K-1ax4lP0Agw-00dJlU; Mon, 08 Aug 2016 10:27:09 +0200 In-Reply-To: <8360rck7kd.fsf@gnu.org> X-Provags-ID: V03:K0:ajfAL8TI5MML6VjWzk5JjQlYFoPU04EgUAQsvbWC+j5BOSHT5dh omVfg55Sez3Bzkh5IDobeWoxUYw18TxTPVMg3cGUTLrVejjEkTCNLnrVPcQkIL7xMcmUJCJ yKK6dIVMloicVCfSuV1rBmSUFqsqmZ+Oz7y/f26O0NF2FDM865u4xM6SYULDzyh8Y1z1TkO 57d5rUnGpCaVKtvzi36tg== X-UI-Out-Filterresults: notjunk:1;V01:K0:tlDTsBInyiI=:yGryOBH/GU5WFjJhFGjxKl 8B2k6yKhW3crshtA4yjbjqY4O1GU2HN/7RnmUnvXtRJyq5gsc7Hu6zWBfiSjDpKq0hlqJKi/W 47MHg97L9Ty6sA4JgbVXAVYS0vcBsMNW29hFJtMnfzIqapIEml9/sACZIXbhoTJBPSKN8MJPZ c3PkDq/fNg+jkrZlccD7we7p8rVZzSe8KqdAwx330m/+7DOV1HXPTB8elhpbs0Y9OboVY2Xpt jZRu61evxRR8R2qDyYu95RbPWW6Qid2oc0Cpvug2eYaKb2koxflTsLKVDGZnPQB5M8DVEwc6d tWHTnYm+kbIME0Zl7LXzDxc7GhutjpXWJxYWRV8a4rLJkrOkxfW2NrbCI8CLN8eWXc6RpU7TD 65Stk5cU3wrVHlrTKS+myG4MQyLHa51KcZDEKo8ZpcG0arZ2qhE8xmufW452TKxSuUe/krz2D AExGMdfj584uX2T6GqDReVndqEN7fx5EvzVCmz5yJBiZAjTJ2RHFnrLgSIEH8y5XiujFWnIZ9 3+01n4Pn5411RPuMvIaGrET0FbqAC45GGRWMTzBabtvqbs0VdGMn4bxumsmtyCQFQ0swh22dM GEJuDnV9FbJAdhZfNa6+yt7H6LX+o1B9vmEBVhq4G6cKxuMzUD6fdL+7O+JauWbMW9iXJ8nYI Xu1rFOYmPqsUBBNbtOn7NWC60ZY9tn2YZcHYCvSsfvVmb2MHmONyynXT88lZBnqgGAY+RKvRB KXv05ofgs5U7Ve9PPlDyXqYhfqjjUmjqPyBMcsvgMANzh4/DK1RqtfrY4mr8bVnh1MXMkuDW X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.22 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:206477 Archived-At: > You started by saying: > >> (progn >> (setq minibuffer-less-frame (make-frame '((minibuffer . nil)))) >> (setq minibuffer-only-frame (make-frame '((minibuffer . only)))) >> >> (set-frame-parameter >> minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-o= nly-frame)) >> (frame-parameter minibuffer-less-frame 'minibuffer)) >> [...] >> But if the frame is minibuffer-less and uses the minibuffer window of= >> some other frame, we return as value nil although the real, internal >> frame parameter's value (not the one produced by the >> >> store_in_alist (&alist, Qminibuffer, >> (! FRAME_HAS_MINIBUF_P (f) ? Qnil >> : FRAME_MINIBUF_ONLY_P (f) ? Qonly >> : FRAME_MINIBUF_WINDOW (f))); >> >> construct) is actually that window. Otherwise, evaluating the >> =E2=80=98set-frame-parameter=E2=80=99 above would have produced an er= ror. > > I don't understand the last sentence: it starts with "otherwise", > which seems to imply that if frame-parameter did not produce nil for a= > minibuffer-less frame, the call to set-frame-parameter would somehow > signal an error. If with emacs -Q I do (let ((minibuffer-only-frame (make-frame '((minibuffer . only))))) (set-frame-parameter nil 'minibuffer (frame-root-window minibuffer-only-frame))) I get an error like "Can=E2=80=99t change the surrogate minibuffer of a f= rame with its own minibuffer". Now, an application that wants to assign a new minibuffer window for an arbitrary frame has two ways to avoid that error: Either it uses (not (eq (window-frame (minibuffer-window frame))) frame) or (not (frame-parameter frame 'minibuffer)) The former is pretty contrived. For example, the coder would have to know that the frame of a minibuffer-only frame's minibuffer window is that frame. So I expect that most applications would prefer the latter. But in order to make that feasible, =E2=80=98frame-parameter=E2=80=99 has= to report nil for the 'minibuffer' parameter of a minibuffer-less frame. However, the judgment whether to raise an error is based on evaluating FRAME_HAS_MINIBUF_P and _not_ on checking the frame parameter. So when you look at the implementation of =E2=80=98set-frame-parameter=E2=80=99, = my sentence is indeed misleading. > However, I don't see any relation between what > (frame-parameter FRAME 'minibuffer) returns and any calls to > set-frame-parameter for the same frame. So what error were you > talking about? I'm not talking about an error here but about the fact that setting a frame's minibuffer window via =E2=80=98set-frame-parameter=E2=80=99 is no= t reflected in the value returned by =E2=80=98frame-parameter=E2=80=99 for that frame's = 'minibuffer' parameter. You have to call =E2=80=98minibuffer-window=E2=80=99 for that= frame to see whether something has effectively changed. > Next, the documentation issue: > > `minibuffer' > Whether this frame has its own minibuffer. The value `t' mean= s > yes, `nil' means no, `only' means this frame is just a minibuf= fer. > 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, a= nd > can not be changed afterwards. > > The sentence "If the value is a minibuffer window (in some other fr= ame), > the frame uses that minibuffer." is misleading. A minibuffer windo= w is > reported iff that window is on the _same_ frame and that frame is n= ot a > minibuffer-only frame. A minibuffer window in some other frame is = never > reported. > > So when do we report t? It sounds like the answer is "never", right? Yes. > IOW, the documentation seems to describe some situation that existed > in the past, and is now OBE due to code changes. Correct? Not really. While t never gets reported, it can be used either in alist specifications or in the 'minibuffer' frame parameter of =E2=80=98make-fr= ame=E2=80=99. It is redundant in both but allowed AFAICT. You can even get away with nonsense like (let ((minibuffer-only-frame (make-frame '((minibuffer . only))))) (set-frame-parameter minibuffer-only-frame 'minibuffer t) (frame-parameter minibuffer-only-frame 'minibuffer)) No error gets reported and the parameter of the minibuffer-only frame appears unchanged. It simply does not matter that it has been set to t internally. >> Note in this context that =E2=80=98minibuffer-window=E2=80=99 returns= the correct >> minibuffer window for its FRAME argument while =E2=80=98set-minibuffe= r-window=E2=80=99 >> does not allow to set the minibuffer window for a specific frame. > > IMO, this is a separate, albeit probably related, issue. Are there > any problems to let set-minibuffer-window allow setting the minibuffer= > window of a frame? Certainly not - if checked and documented orderly. But when you already have a minibuffer window at hand and want to make a new minibuffer-less frame use that window, you currently can write (let ((window (minibuffer-window))) (make-frame `((minibuffer . ,window)))) BTW =E2=80=98set-minibuffer-window=E2=80=99 is a very obscure function. = It's nowhere used and I wouldn't know why and how to use it. > And for that, I proposed: > >>> But I haven't checked all places because I rather soonish stumbled u= pon >>> things like >>> >>> (eq (cdr (or (assq 'minibuffer initial-frame-alist) >>> (assq 'minibuffer window-system-frame-alist) >>> (assq 'minibuffer default-frame-alist) >>> '(minibuffer . t))) >>> t) >>> >>> in =E2=80=98frame-notice-user-settings=E2=80=99. And one revealing = comment is in >>> =E2=80=98set-frame-configuration=E2=80=99: >>> >>> ;; Since we can't set a frame's minibuffer status, >>> ;; we might as well omit the parameter altogether. >> >> We could simply change the above code to follow suit. > > To which you replied: > >> Change what? > > Obviously, change the Lisp snippet shown above, which expects to see a= > nil minibuffer parameter for minibuffer-less frames. Change it not to= > expect that, and instead test the minibuffer window for whether it is > on the same frame or not. If you mean the snippet (eq (cdr (or (assq 'minibuffer initial-frame-alist) ... t) then I suppose that it is correct: The value t _is_ meaningful for the alist variables. It just never gets reported for an actual frame. In frameset.el Juanma wrote about the 'minibuffer' frame parameter: ;; - `minibuffer': It can contain a reference to a live window, which can= not ;; be serialized. Because of Emacs' idiosyncratic treatment of this ;; parameter, frames created with (minibuffer . t) have a parameter ;; (minibuffer . #), while frames created with ;; (minibuffer . #) have (minibuffer . nil), which is madnes= s ;; but helps to differentiate between minibufferless and "normal" frame= s. Here I think that Juanma's wrong BTW. It does not help IMHO. ;; So, changing (minibuffer . #) to (minibuffer . t) allows ;; Emacs to set up the new frame correctly. Nice, uh? But for the rest I fully agree with him. And his (local) fix explains why t would be a good value. So I still do not know what you propose to change. >> But for a minibuffer-less frame we >> OT1H store the minibuffer window in that parameter and OTOH we report= >> the value nil for that parameter in =E2=80=98frame-parameters=E2=80=99= =2E > > I think we should report the window, i.e. the actual value stored in > that parameter. [...] > In general, I prefer to > report the actual values whenever possible, especially when we have no= > reason to hide the value from Lisp applications. Modulo the fact that, as I mentioned above, some application might want to use (not (frame-parameter frame 'minibuffer)) to check whether it is allowed to change the minibuffer window of an arbitrary frame. >> As mentioned before, removing the special treatment of the 'minibuffe= r' >> parameter in =E2=80=98frame-parameters=E2=80=99 would imply that Elis= p code relying on >> the values we report currently might be broken in the future. > > And my suggestion to that was to fix that code, wherever we find it. frameset.el already fixes the code internally so we would have to revert those fixes. That's hairy. And I don't know how many times anyone else already has invented a workaround for all these idiosyncrasies. >> Things would be much clearer if we had provided some orthogonality of= >> =E2=80=98minibuffer-window=E2=80=99 and =E2=80=98set-minibuffer-windo= w=E2=80=99. > > Not sure what you mean by "orthogonality" here. I meant "duality". In the sense that both should take a FRAME argument. martin