Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Tue, 09 Aug 2016 19:34:20 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > Another alternative would be to return a window in both cases.
> 
> But then we can't discriminate minibuffer-less from normal frames by
> looking at the parameter value only.

We can look at what window-frame returns for that window, can't we?

>  > We have already a few cases where frame-parameter returns a value
>  > different from the one specified when make-frame was called.  There's
>  > nothing wrong about that, if it's Emacs that chooses the actual value.
> 
> This goes both ways.  With (2) Emacs would choose nil when
> ‘set-frame-position’ explicitly asks for a window.  And with no
> 'minibuffer' specified we'd have to return t or a window in any case.

Yes, but IMO nil is not a meaningful value.  If we know better, we
should return a more concrete value.

>  > Do you still prefer (2)?  I prefer storing a window because then we
>  > could naturally return it, like we do with frame colors.
> 
> C code never consults the frame parameter.  Elisp code currently
> consults the parameter in four places only, three of them to find out
> whether the frame is minibuffer-only.  If Elisp code wants the window,
> it uses ‘minibuffer-window’ which handles all types of frames.  And with
> (2) the values t, nil and 'only' would immediately tell the type of any
> frame.

Yes, of course, the current situation is not impossible.  We are
talking about improving it.