bug#4543: window-full-height-p

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 26 Sep 2009 21:01:36 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 4543@emacsbugs.donarmstrong.com, monnier@IRO.UMontreal.CA
> 
>  >>  > Why doesn't it make sense?  The computed value of new_frame_total_cols
>  >>  > is used to enlarge only the frame's root window:
>  >>  >
>  >>  >   if (new_frame_total_cols != FRAME_TOTAL_COLS (f))
>  >>  >     {
>  >>  >       set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2);
>  >>  >
>  >>  > And for the root window, FRAME_TOTAL_COLS is correct, I think.  The
>  >>  > window configuration, however complex, does not affect the root
>  >>  > window, does it?
>  >>
>  >> With Emacs -Q I can evaluate
>  >>
>  >> (set-window-scroll-bars nil 0 nil)
>  >>
>  >> to remove the scroll bar from the *scratch* window keeping the window
>  >> size unaltered.  When I now evaluate
>  >>
>  >> (scroll-bar-mode -1)
>  >>
>  >> the width of the frame shrinks and with it the number of columns used
>  >> for text in the *scratch* window.  This doesn't make sense.
>  >
>  > Agreed.  But I must be missing something because I don't see how this
>  > behavior is related to the code you quoted above.
> 
> Indeed.  The above quotation should have started with
> 
>  >> The problem I see is that the value for new_frame_total_cols
>  >> calculated by change_frame_size_1 as
>  >>
>  >>    /* Compute width of windows in F.
>  >>       This is the width of the frame without vertical scroll bars.  */
>  >>    new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth);
>  >>
>  >>    /* Round up to the smallest acceptable size.  */
>  >>    check_frame_size (f, &newheight, &newwidth);
>  >>
>  >> doesn't make sense for more complex window configurations.
> 
> in order to make clear that the assignment to new_frame_total_cols is
> reponsible for the behavior I sketched.

We are looping: the more complex window configurations are irrelevant
for the root window, I think.

>  Or the fact that setting `scroll-bar-mode' may trigger
> frame-resizing in the first place.

What I'm missing is how the code fragments you show are related to the
problematic behavior when `scroll-bar-mode' is toggled.