Re: About the 'minibuffer' frame parameter

[martin rudalics]

>> (1) Make sure that store_frame_param doesn't store invalid parameter
>>       values.
>>
>> (2) Never store a minibuffer window as frame parameter.
>>
>> (3) Have ‘frame-parameter’ return the 'minibuffer' parameter as stored
>>       internally.  If no stored value is available, return t.
>>
>> (4) Wait for regression reports.
>>
>> (5) Fix the documentation.
>>
>> (6) Fix/remove related comments.
>
> I'm okay with that, but I'm surprised by (2): won't storing the
> minibuffer window there allow us to report the correct value in (3)?
> What am I missing?

If we did that we would invert the values returned by ‘frame-parameter’
for the "normal" frame and minibuffer-less frame cases.  Currently, we
return the minibuffer window for a normal frame and nil for a
minibuffer-less frame.  You would return the minibuffer window for a
minibuffer-less frame and t for a normal frame.  Correct?

This would have the benefit that after

  (set-frame-parameter minibuffer-less-frame 'minibuffer some-minibuffer-window)

the value returned by ‘frame-parameter’ would be consistent with the
requested value.  However, most minibuffer-less frames are created via

  (make-frame '((minibuffer . nil)))

and whatever we do here we would introduce another inconsistency: Either
the stored value is the minibuffer window chosen by Emacs and the value
returned by ‘frame-parameter’ would not be the value from the PARAMETERS
argument of ‘make-frame’.  Or we would sometimes return nil and
sometimes a window as value of the 'minibuffer' frame parameter of a
minibuffer-less frame.

Given the fact that changing the frame parameter of a minibuffer-less
frame is a pretty rare operation, I would prefer the solution sketched
in (2).  WDYT?

martin