GNU bug report logs -
#4543
window-full-height-p
Previous Next
Reported by: Glenn Morris <rgm <at> gnu.org>
Date: Thu, 24 Sep 2009 03:50:04 UTC
Severity: wishlist
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> 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.
>> 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.
martin
This bug report was last modified 15 years and 236 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.