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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 12 Jul 2013 12:12:49 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14825@debbugs.gnu.org
> 
>  > 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).

??? How do you change the default face's font of a live frame without
remapping it?

>  > 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.

Does window-text-height still reports the actual number of text lines
in a window?

>  >> 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)
> ...

Not just font: it's an entirely different face, which has a box
attribute, and therefore different dimensions even if the same font is
being used as in the text area.

>  > 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.

Why do you need to?  Isn't the root window enough?

>  >> 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.

Which is why we don't need to bother that it will become unreliable,
as it is already there.

>  >> 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?

Similar to the ones we have now, except they will take the font and
line-spacing into account.

>  >  . 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'?

As long as we leave them as they are, yes.

>  >  . 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'?

We would have one that counts in canonical lines, the other that
counts in lines of the current default face.

> Maybe you could enumerate two or three existing functions

You already did above.

> and tell me what they currently do wrong and what they or their
> counterparts in the new API would have to do instead.

I was doing that since the beginning of this bug report.  I obviously
completely failed.