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

[Eli Zaretskii]

> Date: Thu, 11 Jul 2013 08:27:26 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14825@debbugs.gnu.org
> 
>  >> How would you report the size of an internal window composed of two leaf
>  >> windows showing buffers with different default character sizes?
>  >
>  > As a sum of the line counts of the two children, obviously.
> 
> That would mean lots of fun.  Consider an Emacs frame built from three
> windows like this
> 
>   ------------------
> |        |         |
> |   A    |         |
> |        |         |
> |--------|    B    |
> |        |         |
> |   C    |         |
> |        |         |
>   ------------------
> 
> where A and B have the same character heights and the one of C is twice
> that.  The parent window of A and C would have a larger height than B.
> How would window_resize_check handle that?

I think we are miscommunicating.  I didn't say that solving this bug
will make things easier for the core Emacs developers.  I said that
currently we have an array of functions that lie through their teeth
about their contract.  Here's a typical example:

  (window-text-height &optional WINDOW)

  Return the height in lines of the text display area of WINDOW.
  WINDOW must be a live window and defaults to the selected one.

  The returned height does not include the mode line, any header line,
  nor any partial-height lines at the bottom of the text area.

These are externally visible, documented APIs; we cannot say they
measure in line units, while in fact they measure in some other
obscure units.  And please note that someone who is not privy to the
Emacs internals (on the C level) will not be able to get to the bottom
of this once they bump into the problems this creates.  The truth is
buried deep behind macros and accessor functions whose names are as
misleading as those of the APIs that expose them.

This must be rectified.  We can either fix the doc strings, or
(better) introduce a separate set of APIs that counts lines in units
of the default face.

> PS: It can be easily done as soon as we do resizing pixelwise.  But it
> would break a few functions like `window-edges' in the sense that the
> lower edge of A would not be necessary equal to the upper edge of C.

Functions like window-edges shouldn't rely on this in the first place.
In any case, it certainly makes no sense to bend public interfaces so
much, just because that makes things easier internally.  It just took
me the better part of this week to repair damage due to this
misconception to something as basic as scrolling.  Isn't that reason
good enough to consider this a serious shortcoming?