bug#4543: window-full-height-p

[martin rudalics <rudalics@gmx.at>]

 > Well, maybe I'm missing something, but this seems quite clear to me.
 > SET_FRAME_COLS sets both f->text_cols and f->total_cols, the former
 > counts the width of only the text area of the display, the latter
 > counts the total frame area that includes the scroll bars and the
 > fringe.

It doesn't.  Make a frame with two side-by-side windows with scrollbars.
Only one scrollbar is counted in f->total_cols.  f->total_cols is an
artifact whose purpose escapes me so far.  And fringe sizes can be set
on a per window basis, so counting them seems completely useless.

 > Both the scroll bar and the fringe may be absent, the most
 > trivial example is the text terminal display.

In that case f->text_cols equals f->total_cols so we can use the former.

 >> What are the scrollbars of a frame, I'm asking myself.  If we
 >> define a frame as a collection of windows and frame-width as the width
 >> of the widest window in that frame, things are deceptively simple.  But
 >> the calculations sketched above are a little over my head.
 >
 > If a frame has scroll bars, they are all of the same size, so counting
 > this on the frame level seems reasonable.

When I have two side-by-side windows and toggle scroll-bar-mode the
frame resizes by exactly the same amount as if it had only one window.
So the size available for displaying text within windows changes
relatively to the number of side-by-side window I have when toggling
scroll-bar mode.  This is not reasonable.  I'd prefer the frame size to
not change at all when I toggle scroll-bar-mode.  If it is supposed to
change, then all windows would have to change their total width too.

 >>  > What's wrong with this (taken from frame.c:frame-parameters) as the
 >>  > frame height:
 >>  >
 >>  >   height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f));
 >>
 >> new_text_lines is for a pending size change and zero otherwise.  You
 >> probably mean text_lines
 >
 > I don't see any reason not to use new_text_lines as well: first, you
 > will be consistent with frame-parameters (a Good Thing, IMO), and
 > second, your code will work even if redisplay didn't yet kick in.

The code is supposed to work when no size change is pending and the
comment in frame.h says that new_text_lines is zero in that case.

 >> what are canonical characters?
 >
 > Each line on the display can have its own height, remember?  For
 > example, look at a single-window frame whose window displays an
 > "*info*" buffer -- there are several lines that use a larger fonts,
 > and take more screen estate than others.  You don't want such a window
 > to screw up window-height or frame-height, do you?

Honestly, I never want my frame size to change unless I explicitly ask
it to do so.  And I never care about the size of my frame measured in
lines or columns.  What does annoy me is that a maximized Emacs frame
changes its size when I toggle scroll-bars or resize the minibuffer.
And IIUC this problem is not restricted to Windows.

 > So to get this right, Emacs measures these in units of canonical
 > characters, which are characters from the frame's default font.  I
 > think the size of this canonical character is given by the font info,
 > but I'm not sure.

 >> Then why not use the height of the frame-root-window directly?  No need
 >> to subtract one value from the other.
 >
 > Fine, if you can get this efficiently in C.

Why in C?  It's a simple lookup written in Elisp.

martin