[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#4543: window-full-height-p
From: |
Eli Zaretskii |
Subject: |
bug#4543: window-full-height-p |
Date: |
Sat, 26 Sep 2009 23:17:16 +0300 |
> 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.
- bug#4543: window-full-height-p, (continued)
- bug#4543: window-full-height-p, Stefan Monnier, 2009/09/25
- bug#4543: window-full-height-p, martin rudalics, 2009/09/26
- bug#4543: window-full-height-p, Stefan Monnier, 2009/09/25
- bug#4543: window-full-height-p, martin rudalics, 2009/09/26
- bug#4543: window-full-height-p, Eli Zaretskii, 2009/09/26
- bug#4543: window-full-height-p, martin rudalics, 2009/09/26
- bug#4543: window-full-height-p, Eli Zaretskii, 2009/09/26
- bug#4543: window-full-height-p, martin rudalics, 2009/09/26
- bug#4543: window-full-height-p,
Eli Zaretskii <=
- bug#4543: window-full-height-p, martin rudalics, 2009/09/27
- bug#4543: window-full-height-p, Glenn Morris, 2009/09/25
- bug#4543: window-full-height-p, martin rudalics, 2009/09/25
- bug#4543: window-full-height-p, Stefan Monnier, 2009/09/25