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

[martin rudalics <rudalics@gmx.at>]

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

I never do.  But hopefully Juanma's recipe works.  We've been discussing
this issue with Drew a couple of weeks ago.  He said that he's
frequently using the feature that changing a frame's default face also
changes the frame's size and that of its scrollbars and so on.  And I
implicitly said that this feature is the source of all evil in the
current frame sizing code and that any such feature should be build on
top of code that keeps frame and other sizes invariant when changing the
default face.  IMO it's rather that what we have to discuss than whether
to count the real number of lines of a window or some abstraction.

 > 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
newlines appearing in the window?  The number of line breaks (maybe
additionally added by word wrapping)?  Or is it, as here, the total
pixel height of the window minus the pixel heights of the window's
header and mode line, divided by the frame's default character height.
Using the buffer's default character height as divisor is yet another
artefact IMHO.

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

Indeed.  And this is something that doesn't quite work here.  I'm using
a box attribute and bold face and when creating a new frame the heights
of mode and headerline are not "guessed" correctly to accomodate them so
fitting the new frame to its buffer's size doesn't come up correctly.  I
have yet to look into this.

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

OK.  I at least have to be able to relate (1) the size of the root
window to that of its frame and (2) the size of the root window to that
of its children.

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

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

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

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

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.

martin