From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: About the 'minibuffer' frame parameter Date: Sun, 07 Aug 2016 16:54:58 +0300 Message-ID: <8360rck7kd.fsf@gnu.org> References: <579E3F9E.8020200@gmx.at> <83h9azl4s1.fsf@gnu.org> <57A4C0DE.3060506@gmx.at> <837fbvkofs.fsf@gnu.org> <57A5AF03.30807@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1470578160 9370 195.159.176.226 (7 Aug 2016 13:56:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2016 13:56:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 07 15:55:56 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 1bWOYO-0000uW-O0 for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 15:55:48 +0200 Original-Received: from localhost ([::1]:52795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWOYL-0002J3-IV for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 09:55:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWOXk-0002FN-Dh for emacs-devel@gnu.org; Sun, 07 Aug 2016 09:55:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWOXe-0000Yg-SP for emacs-devel@gnu.org; Sun, 07 Aug 2016 09:55:07 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWOXe-0000YM-P8; Sun, 07 Aug 2016 09:55:02 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3430 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bWOXc-0005Fo-O1; Sun, 07 Aug 2016 09:55:01 -0400 In-reply-to: <57A5AF03.30807@gmx.at> (message from martin rudalics on Sat, 06 Aug 2016 11:33:55 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:206465 Archived-At: > Date: Sat, 06 Aug 2016 11:33:55 +0200 > From: martin rudalics > Cc: emacs-devel@gnu.org I must admit I'm a bit confused about the issues you raise. So let me make a step or two back, before we continue. 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-only-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 > ‘set-frame-parameter’ above would have produced an error. 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. 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? Next, the documentation issue: `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. The sentence "If the value is a minibuffer window (in some other frame), the frame uses that minibuffer." is misleading. A minibuffer window is reported iff that window is on the _same_ frame and that frame is not 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? IOW, the documentation seems to describe some situation that existed in the past, and is now OBE due to code changes. Correct? > Note in this context that ‘minibuffer-window’ returns the correct > minibuffer window for its FRAME argument while ‘set-minibuffer-window’ > 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? > I'm not sure how to deal with this situation. Personally, I'd prefer to > report the real, internal 'minibuffer' parameter And I implicitly agreed with that. > but am afraid that might break existing code. And for that, I proposed: > > But I haven't checked all places because I rather soonish stumbled upon > > 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 ‘frame-notice-user-settings’. And one revealing comment is in > > ‘set-frame-configuration’: > > > > ;; 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. > Initially I only wanted to simplify code like > > (FRAME_HAS_MINIBUF_P (f) && !FRAME_MINIBUF_ONLY_P (f)) > > because once f has been created, FRAME_HAS_MINIBUF_P (f) and > !FRAME_MINIBUF_ONLY_P (f) invariantly hold for the entire lifetime of f. > A bit field telling whether a frame owns a minibuffer or is > minibuffer-only/-less seems more practical instead of these macros. The > value stored in that bit field would have to reflect the value stored in > the 'minibuffer' frame parameter. 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 ‘frame-parameters’. I think we should report the window, i.e. the actual value stored in that parameter. > We could either modify that code in store_frame_param > > if (EQ (prop, Qminibuffer) && WINDOWP (val)) > { > if (! MINI_WINDOW_P (XWINDOW (val))) > error ("Surrogate minibuffer windows must be minibuffer windows"); > if ((FRAME_HAS_MINIBUF_P (f) || FRAME_MINIBUF_ONLY_P (f)) > && !EQ (val, f->minibuffer_window)) > error ("Can't change the surrogate minibuffer of a frame with its own > minibuffer"); > > /* Install the chosen minibuffer window, with proper buffer. */ > fset_minibuffer_window (f, val); > } > > to store Qnil instead of the minibuffer window or do away with the > special treatment of the 'minibuffer' parameter in ‘frame-parameters’ as > I mentioned earlier. I like the latter possibility much better. In general, I prefer to report the actual values whenever possible, especially when we have no reason to hide the value from Lisp applications. > As mentioned before, removing the special treatment of the 'minibuffer' > parameter in ‘frame-parameters’ would imply that Elisp 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. > Things would be much clearer if we had provided some orthogonality of > ‘minibuffer-window’ and ‘set-minibuffer-window’. Not sure what you mean by "orthogonality" here.