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

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

[Eli Zaretskii]

To reproduce:

 emacs -Q
 Click S-mouse-1 and select "Change Buffer Font"
 Under "Size" type 6 and click OK

You should now have *scratch* buffer displayed with a very small font

 Hit RET 5 times to have a 10-line buffer
 C-x 2
 C-u 10 C-x ^

You should now have 2 windows displaying *scratch*, the lower one about
10 lines tall.

 C-x o
 C-x 2
  => Window #<window 0x3817df0 on *scratch*> too small for splitting

But that window is 10 lines tall, while the minimum window height is 4
lines, so I would expect Emacs to honor the request and produce 2
windows.  And indeed, if I do the same with a 10-line window without
making the font smaller, the window is split.

The reason for this seems to be that window.el and window.c do all
calculations in canonical lines, which is incorrect when the font of the
default face changes.  Moreover, the documentation barely hints on the
fact that "lines" actually means "canonical-height lines" in almost all
window-* functions that deal with vertical dimensions.



In GNU Emacs 24.3.50.32 (i686-pc-mingw32)
 of 2013-07-08 on HOME-C4E4A596F7
Bzr revision: 113326 jan.h.d@swipnet.se-20130708132613-wcxq7gxkq12qvhp3
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --prefix=/d/usr --enable-checking CFLAGS=-O0 -gdwarf-2 -g3
 CPPFLAGS=-DGLYPH_DEBUG=1'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  buffer-face-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<return> <return> <return> <return> <return> <S-down-mouse-1> 
C-x 2 C-u 1 0 C-x ^ C-x o C-x 2 C-x o M-x r e p o r 
t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Buffer-Face mode enabled
byte-code: Window #<window 0x3817df0 on *scratch*> too small for splitting

Load-path shadows:
None found.

Features:
(shadow sort nadvice gnus-util mail-extr emacsbug message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils face-remap time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process w32notify w32 multi-tty emacs)
To: 
Subject: 
--text follows this line--

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

[martin rudalics]

 > The reason for this seems to be that window.el and window.c do all
 > calculations in canonical lines, which is incorrect when the font of the
 > default face changes.  Moreover, the documentation barely hints on the
 > fact that "lines" actually means "canonical-height lines" in almost all
 > window-* functions that deal with vertical dimensions.

Currently, all window and frame sizing functions are based on canonical
character sizes.  This will change when we do resizing pixelwise.

However, your example seems contrived: You don't change the default face
but the buffer's default face.  In many cases, split-window is followed
by displaying another buffer in the new window so this buffer's default
might not be appropriate for the other buffer anyway.

martin

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

[Eli Zaretskii]

> Date: Tue, 09 Jul 2013 11:09:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14825@debbugs.gnu.org
> 
>  > The reason for this seems to be that window.el and window.c do all
>  > calculations in canonical lines, which is incorrect when the font of the
>  > default face changes.  Moreover, the documentation barely hints on the
>  > fact that "lines" actually means "canonical-height lines" in almost all
>  > window-* functions that deal with vertical dimensions.
> 
> Currently, all window and frame sizing functions are based on canonical
> character sizes.  This will change when we do resizing pixelwise.

Resizing is only part of the problem.  There are functions that are
unrelated to resizing, which report dimensions in canonical units.
They should at least document this fact in the doc string, if not fix
it.  (The fix is not too hard, btw; see window-screen-lines for an
example.)

> However, your example seems contrived: You don't change the default face
> but the buffer's default face.  In many cases, split-window is followed
> by displaying another buffer in the new window so this buffer's default
> might not be appropriate for the other buffer anyway.

We have this problem already: one could split the window, and _then_
change the default face in one of the child windows.

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

[martin rudalics]

 >> Currently, all window and frame sizing functions are based on canonical
 >> character sizes.  This will change when we do resizing pixelwise.
 >
 > Resizing is only part of the problem.  There are functions that are
 > unrelated to resizing, which report dimensions in canonical units.
 > They should at least document this fact in the doc string, if not fix
 > it.  (The fix is not too hard, btw; see window-screen-lines for an
 > example.)

How would you report the size of an internal window composed of two leaf
windows showing buffers with different default character sizes?

martin

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

[Eli Zaretskii]

> Date: Wed, 10 Jul 2013 09:20:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14825@debbugs.gnu.org
> 
>  >> Currently, all window and frame sizing functions are based on canonical
>  >> character sizes.  This will change when we do resizing pixelwise.
>  >
>  > Resizing is only part of the problem.  There are functions that are
>  > unrelated to resizing, which report dimensions in canonical units.
>  > They should at least document this fact in the doc string, if not fix
>  > it.  (The fix is not too hard, btw; see window-screen-lines for an
>  > example.)
> 
> 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.

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

[martin rudalics]

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

martin

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.

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?

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

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

[Eli Zaretskii]

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

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.

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

We could just have a warning there about not using these functions to
count text lines in a window.

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

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.

> So when you show another buffer in that window, the window's height
> might change nominally although it does not change visually.

Right.

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

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

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

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

I didn't suggest that.  My suggestion pols down to this:

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

 . Add a separate set of APIs for counting the number of default-face
   text lines and characters in a window.

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

[martin rudalics]

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

 >> If we want to put this explanation into the doc-strings, we'd probably
 >> have to change the doc-strings of frame functions too.
 >
 > We could just have a warning there about not using these functions to
 > count text lines in a window.

I don't understand - frame functions usually don't count text lines.

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

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

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

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

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

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

 >  . 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'?  Maybe you could
enumerate two or three existing functions and tell me what they
currently do wrong and what they or their counterparts in the new API
would have to do instead.

martin

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

[Eli Zaretskii]

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

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

[Juanma Barranquero]

On Fri, Jul 12, 2013 at 3:29 PM, Eli Zaretskii <eliz@gnu.org> wrote:

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

(modify-frame-parameters FRAME '((font . FONTSPEC)))  ??

  J

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

[martin rudalics]

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

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.

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

[martin rudalics]

 >> What is "the actual number of text lines in a window"?
 >
 > The number of glyph rows visible in the window.

So this is something that changes with the text displayed in the window
and not only when changing the buffer's default face.  Wouldn't your
proposal then imply that before I want to split a window I have to check
how many lines it actually displays?  So if I'm currently watching an
*info* buffer, the height of the new window would depend on whether I'm
currently seeing a title line or not.

Also, would we then have four different units to measure window heights
- frame lines, pixels, buffer lines, displayed lines?

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

In what sense?  I obviously agree because I consider it wrong when
changing a frame's default face can affect its size but I suppose what
you have in mind is something different.

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

I haven't looked at it yet.  Where is it?  Does it accept arbitrary
buffer start and end points?  Does it return pixel sizes?

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

So we should call `window-screen-lines' before splitting a 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.

I don't understand all implications of such an approach yet but in any
case we can try to support it as an option.

martin

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

[Eli Zaretskii]

> Date: Sat, 13 Jul 2013 15:56:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14825@debbugs.gnu.org
> 
>  >> What is "the actual number of text lines in a window"?
>  >
>  > The number of glyph rows visible in the window.
> 
> So this is something that changes with the text displayed in the window
> and not only when changing the buffer's default face.

No, it doesn't.  I meant the number of lines of the default face.

> Also, would we then have four different units to measure window heights
> - frame lines, pixels, buffer lines, displayed lines?

Only 3, not 4.

>  >>  > 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.
> 
> In what sense?

In the sense that we have been discussing for the last several
months.  I don't think I need to repeat all that.

> I obviously agree because I consider it wrong when changing a
> frame's default face can affect its size but I suppose what you have
> in mind is something different.

If we agree, we don't have to talk about this aspect any more.

>  > Well, you now have window-screen-lines ;-)
> 
> I haven't looked at it yet.  Where is it?

In simple.el.  If you want to move it to window.el, I won't mind.

> Does it accept arbitrary buffer start and end points?

It measures in units of the default-face lines, so it doesn't care
about where in the buffer are you.

> Does it return pixel sizes?

No, line sizes.

>  >> 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.
> 
> So we should call `window-screen-lines' before splitting a window?

Probably.

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

 > To reproduce:
 >
 >   emacs -Q
 >   Click S-mouse-1 and select "Change Buffer Font"
 >   Under "Size" type 6 and click OK
 >
 > You should now have *scratch* buffer displayed with a very small font
 >
 >   Hit RET 5 times to have a 10-line buffer
 >   C-x 2
 >   C-u 10 C-x ^
 >
 > You should now have 2 windows displaying *scratch*, the lower one about
 > 10 lines tall.
 >
 >   C-x o
 >   C-x 2
 >    => Window #<window 0x3817df0 on *scratch*> too small for splitting
 >
 > But that window is 10 lines tall, while the minimum window height is 4
 > lines, so I would expect Emacs to honor the request and produce 2
 > windows.  And indeed, if I do the same with a 10-line window without
 > making the font smaller, the window is split.

I attached a patch that tries to fix this scenario.  Please have a
look.

Thanks, martin

[-- Attachment #2: split-window-below.diffs --]
[-- Type: text/plain, Size: 1378 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index af35f9abe6..7470ffc1d3 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5365,10 +5365,22 @@ split-window-below
   (let ((old-window (selected-window))
 	(old-point (window-point))
 	(size (and size (prefix-numeric-value size)))
-        moved-by-window-height moved new-window bottom)
-    (when (and size (< size 0) (< (- size) window-min-height))
+        line-height moved-by-window-height moved new-window bottom)
+    (cond
+     ((and size (< size 0) (< (- size) window-min-height))
       ;; `split-window' would not signal an error here.
       (error "Size of new window too small"))
+     ((and (not size)
+           (< (setq line-height (window-default-line-height))
+              (frame-char-height))
+           (>= (/ (float (window-size nil nil t)) line-height)
+               window-min-height))
+        ;; As a special case when SIZE is not specified and the
+        ;; selected window has a default line height that is smaller
+        ;; than the character height of its frame, try to split the
+        ;; window even if the resulting windows would otherwise
+        ;; violate the `window-min-height' contstraints (Bug#14825).
+      (setq size (/ (window-size) 2))))
     (setq new-window (split-window nil size))
     (unless split-window-keep-point
       (with-current-buffer (window-buffer)

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

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

[...]

>> But that window is 10 lines tall, while the minimum window height is 4
>> lines, so I would expect Emacs to honor the request and produce 2
>> windows.  And indeed, if I do the same with a 10-line window without
>> making the font smaller, the window is split.
>
> I attached a patch that tries to fix this scenario.  Please have a
> look.

This bug report is seven years old, and then Martin posted a patch about
a year ago that received no followup.  Eli?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  14825@debbugs.gnu.org
> Date: Mon, 21 Sep 2020 14:38:30 +0200
> 
> >> But that window is 10 lines tall, while the minimum window height is 4
> >> lines, so I would expect Emacs to honor the request and produce 2
> >> windows.  And indeed, if I do the same with a 10-line window without
> >> making the font smaller, the window is split.
> >
> > I attached a patch that tries to fix this scenario.  Please have a
> > look.
> 
> This bug report is seven years old, and then Martin posted a patch about
> a year ago that received no followup.  Eli?

If Martin still thinks the patch is good to go, please install it.

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

[martin rudalics]

 > If Martin still thinks the patch is good to go, please install it.

It's not good to go.  I fixed this problem here in a more profound way
but it will take some time to polish it up and push it.

martin

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

[Eli Zaretskii]

> Cc: 14825@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 21 Sep 2020 19:46:40 +0200
> 
>  > If Martin still thinks the patch is good to go, please install it.
> 
> It's not good to go.  I fixed this problem here in a more profound way
> but it will take some time to polish it up and push it.

Thanks in advance.