RE: About the 'minibuffer' frame parameter

[Drew Adams <drew.adams@oracle.com>]

> 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:
> 
> (1) Emacs does redirect output to the minibuffer window of the frame
>     specified via ‘set-frame-parameter’.  This follows from the
>     experiment above because you see the value reported by
>     ‘frame-parameter’ appear in different minibuffer windows.

Yes.

> (2) Any such redirection is not reflected in the 'minibuffer' value
>     reported by ‘frame-parameter’: That value remains nil invariably.
> 
> 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.
> 
> From (2) the 'minibuffer' value assigned by ‘set-frame-parameter’ is not
> reflected in the 'minibuffer' value returned by ‘frame-parameter’.  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:
> 
> `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.
     ^^^^^^^
     cannot (typo)
 
> 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 ‘frame-parameter’ reports, the value of the frame
> parameter stored by Emacs internally is the window specified by
> (frame-root-window minibuffer-only-frame).  The routine constructing the
> ‘frame-parameters’ 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 #<window 4 on  *Minibuf-0*>

Yes.

> appear in the minibuffer window.  This is a window on the initial frame.
> ‘frame-parameter’ 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 ‘frame-parameter’ to report
> a minibuffer window "in some other frame" as the manual suggests.
> 
> 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?
> 
> 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 ‘make-frame’
> 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, ‘frame-parameter’ is useless for finding the 
> 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 ‘frame-parameter’ there
> are no problems.  On the C-level code works with the "real" value of the
> parameter as set by ‘set-frame-parameter’ and does not have 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.