bug#14825: 24.3.50; split-window-below miscounts window lines

[martin rudalics <rudalics@gmx.at>]

 > Yes, I know.  But note that this extended explanation is also
 > misleading, because it silently assumes that the default face was not
 > remapped.  If the default face _is_ remapped, then "the frame's
 > default font" is ambiguous at best, since '(face-font 'default)' will
 > return a font whose size is not the one meant by the above
 > description.

Much, much worse: The description implies that a frame and its windows
(and its scrollbars, fringes, toolbars) have to be resized when the
default face changes (no remapping involved).

 >> If we want to put this explanation into the doc-strings, we'd probably
 >> have to change the doc-strings of frame functions too.
 >
 > We could just have a warning there about not using these functions to
 > count text lines in a window.

I don't understand - frame functions usually don't count text lines.

 > Yes, but it's not only about the default face.  Did you try setting
 > line-spacing to something non-nil lately?  Try it: it's a lot of fun
 > looking at what window-text-height and its ilk return in that case.

I'll do as soon as I'm able to build.  On my present, old build I don't
see anything abnormal.

 >> Now if the window is the only one on its frame, you would have to change
 >> the frame's nominal height as well
 >
 > The number of lines in the frame does not necessarily need to change,
 > because a frame has other elements, even if it has only one window --
 > the mode line,

... the mode line belongs to the window (albeit in some different font)
...

 > the menu bar, the tool bar, etc.  What matters is the
 > root window, not the frame.  So we can still measure a frame in
 > canonical units.

This means that you no more have sensible means to compare the
sizes and positions of windows with those of their frames.

 >> If OTOH the frame contains more than one window, we would have a
 >> hard time to relate the height of these windows to that of the
 >> frame.
 >
 > The only reliable way of doing that is in pixels anyway.

Currently it's done in lines and columns.

 >> Lifting the present relationship without providing a viable alternative
 >> would be a misconception IMO.
 >
 > That's why I suggested to introduce a separate set of APIs.

What would their specification look like?

 >  . Say in the doc strings of all these functions that their return
 >    values should NOT be used to count lines or columns of text in a
 >    window;

In the doc-strings of `split-height-threshold' or `window-min-height'?

 >  . Add a separate set of APIs for counting the number of default-face
 >    text lines and characters in a window.

I don't understand: Would `window-text-height' be part of this set?  Or
would I have to write `window-default-text-height'?  Maybe you could
enumerate two or three existing functions and tell me what they
currently do wrong and what they or their counterparts in the new API
would have to do instead.

martin