Re: About the 'minibuffer' frame parameter

[martin rudalics]

> They are not clear to me, even on re-reading.

Sorry for being unclear.  Let me try once more: 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?

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.
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.  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.

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.

(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?  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.

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.

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).

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.

Finally evaluate the form

(frame-parameter initial-frame 'minibuffer)

You will see something like

#<window 4 on  *Minibuf-0*>

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?

>> 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))

In general, ‘frame-parameter’ is useless for finding the minibuffer frame.

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.

martin