[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: About the 'minibuffer' frame parameter
From: |
Drew Adams |
Subject: |
RE: About the 'minibuffer' frame parameter |
Date: |
Sat, 6 Aug 2016 09:46:12 -0700 (PDT) |
> 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.
- Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/05
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/05
- RE: About the 'minibuffer' frame parameter, Drew Adams, 2016/08/05
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/05
- RE: About the 'minibuffer' frame parameter, Drew Adams, 2016/08/05
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/05
- RE: About the 'minibuffer' frame parameter, Drew Adams, 2016/08/05
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/06
- RE: About the 'minibuffer' frame parameter,
Drew Adams <=
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/07
Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/05
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/06
- Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/07
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/08
- Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/08
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/09
- Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/09
- Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/09
- Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/09