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

[Eli Zaretskii]

> Date: Sat, 13 Jul 2013 13:10:40 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14825@debbugs.gnu.org
> 
>  > Does window-text-height still reports the actual number of text lines
>  > in a window?
> 
> What is "the actual number of text lines in a window"?

The number of glyph rows visible in the window.

>  >>  >> 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.
> 
> You mean it's not reliable currently?

Yes.

>  >>  >> 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.
> 
> But this is what I asked for here months ago: A function that tells me
> how much space a buffer text would occupy if displayed in a certain
> window

Well, you now have window-screen-lines ;-)

> and what I wrote `window-text-pixel-size' for.  But this is based
> on actual line heights, not necessarily those specified by the buffer's
> default face plus line spacing.  And I suppose moving by lines calls for
> actual line heights too.

Yes, of course.  If you need to count in units of the default face and
also take the line-spacing into consideration, window-screen-lines is
your friend.

>  >>  >  . 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.
> 
> The problem I mentioned earlier still stands.  Variables like
> `split-height-threshold' or `window-min-height' are not reasonably
> buffer local.  Users can bind these variables around `split-window'
> calls to express that the old and new window should not be smaller than
> a certain number of lines.  If these windows will end up to show
> different buffers as after calls of `display-buffer' they usually do,
> it's not clear which interpretation should prevail: `split-window'
> doesn't know which buffer to display in the new window (or, as with
> ispell, in the old window).

Which probably means that split-window should be told what is expected
of it: use canonical lines or lines the current window actually uses.

> Your inital bug report makes perfect sense considering the C-x 2 case
> for a window with a different buffer default face.  So we could handle
> interactive splitting to not produce an error in that case.  For
> non-interactive calls of `split-window-below' you should at least try to
> address the concerns I raise in the last paragraph.

I tried, see above.  But each such issue should be handled on a case
by case basis.  I don't see a one-fits-all kind of solution, because
these APIs are used in different contexts.