Re: About the 'minibuffer' frame parameter

[martin rudalics <rudalics@gmx.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-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.

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’t change the surrogate minibuffer of a frame
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, ‘frame-parameter’ 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 ‘set-frame-parameter’, 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 ‘set-frame-parameter’ is not reflected in
the value returned by ‘frame-parameter’ for that frame's 'minibuffer'
parameter.  You have to call ‘minibuffer-window’ 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' 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?

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 ‘make-frame’.
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 ‘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?

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 ‘set-minibuffer-window’ 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 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.

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 cannot
;;   be serialized.  Because of Emacs' idiosyncratic treatment of this
;;   parameter, frames created with (minibuffer . t) have a parameter
;;   (minibuffer . #<window...>), while frames created with
;;   (minibuffer . #<window...>) have (minibuffer . nil), which is madness
;;   but helps to differentiate between minibufferless and "normal" frames.

Here I think that Juanma's wrong BTW.  It does not help IMHO.

;;   So, changing (minibuffer . #<window...>) 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 ‘frame-parameters’.
 >
 > 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 '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.

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
 >> ‘minibuffer-window’ and ‘set-minibuffer-window’.
 >
 > Not sure what you mean by "orthogonality" here.

I meant "duality".  In the sense that both should take a FRAME argument.

martin