bug-gnu-emacs
[Top][All Lists]
Advanced

[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 19:27:50 +0300

> Date: Sat, 26 Sep 2009 15:41:57 +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.

>  >> I'm not sure, however, whether text-only terminals inherently rely
>  >> on these calculations.  So the question I essentially ask is whether
>  >> the number of total columns of a frame's root-window invariantly
>  >> equals the width of that frame over all possible terminals.
>  >
>  > I think it does, yes.  In any case, the code in change_frame_size_1
>  > _is_ run on text-only terminals (or should I say for frames on
>  > text-only terminals, since we have multi-tty now).
> 
> Fine.  I wasn't entirely sure about
> 
>    dos_set_window_size (&newheight, &newwidth);
> 
> which IIUC does adjust the width value via
> 
>    *rows = ScreenRows ();
> 
> so this eventually does get related back to the frame's root window.

That's true, but only if the original newheight or newwidth are not
supported by the underlying video hardware.  If they are supported,
then they are left at their computed values.

And the DOS display does not support scroll bars anyway.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]