[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About the 'minibuffer' frame parameter
From: |
Eli Zaretskii |
Subject: |
Re: About the 'minibuffer' frame parameter |
Date: |
Tue, 09 Aug 2016 19:21:05 +0300 |
> Date: Tue, 09 Aug 2016 18:07:58 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
>
> >> (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?
Maybe. Another alternative would be to return a window in both cases.
> 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.
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.
> 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?
Do you still prefer (2)? I prefer storing a window because then we
could naturally return it, like we do with frame colors.
- RE: About the 'minibuffer' frame parameter, (continued)
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 <=
- 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/10
- Re: About the 'minibuffer' frame parameter, Stefan Monnier, 2016/08/10
- Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/10
Re: About the 'minibuffer' frame parameter, Eli Zaretskii, 2016/08/10
Re: About the 'minibuffer' frame parameter, martin rudalics, 2016/08/21
Re: About the 'minibuffer' frame parameter, Kaushal Modi, 2016/08/21
Re: About the 'minibuffer' frame parameter, Kaushal Modi, 2016/08/22
Re: About the 'minibuffer' frame parameter, Kaushal Modi, 2016/08/22