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

[martin rudalics]

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

From the Elisp manual:

      Emacs provides several functions for finding the height and width of
   a window.  Except where noted, Emacs reports window heights and widths
   as integer numbers of lines and columns, respectively.  On a graphical
   display, each "line" and "column" actually corresponds to the height
   and width of a "default" character specified by the frame's default
   font.  Thus, if a window is displaying text with a different font or
   size, the reported height and width for that window may differ from the
   actual number of text lines or columns displayed within it.

If we want to put this explanation into the doc-strings, we'd probably
have to change the doc-strings of frame functions too.

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

`window-edges' is a function available to users and as a user of that
function I would expect it to behave in some expected sense.

> In any case, it certainly makes no sense to bend public interfaces so
> much, just because that makes things easier internally.

As I tried to explain twice in this thread, internally I don't care at
all about lines and columns and what they stand for.  The sooner we lift
the impact of faces (and their changes) on the size of windows or frames
the better.

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

I still have to understand what you conisder a misconception here: IIUC
you say that if a buffer has a default face that differs from the
default face of the frame it is shown on, the height of any window
showing that buffer should be calculated in terms of that buffer's face.
So when you show another buffer in that window, the window's height
might change nominally although it does not change visually.

Now if the window is the only one on its frame, you would have to change
the frame's nominal height as well, since otherwise we would get, for
example, a window that's higher than its frame.  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.

Lifting the present relationship without providing a viable alternative
would be a misconception IMO.  For me, changing to a default size of 1
as canonical unit is a viable alternative.

My apologies if what I say here doesn't fit your expectations.  But
doing ad hoc changes to code that has evolved over decades is over my
head.

martin