GNU bug report logs - #14825
24.3.50; split-window-below miscounts window lines

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Eli Zaretskii <eliz@HIDDEN>; dated Mon, 8 Jul 2013 17:54:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 13 Jul 2013 14:39:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 10:39:02 2013
Received: from localhost ([127.0.0.1]:52794 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Uy0yS-0006jt-C3
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2013 10:39:01 -0400
Received: from mtaout20.012.net.il ([80.179.55.166]:49425)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1Uy0yN-0006jc-09
 for 14825 <at> debbugs.gnu.org; Sat, 13 Jul 2013 10:38:56 -0400
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0MPV00A00PZ5P000@HIDDEN> for 14825 <at> debbugs.gnu.org;
 Sat, 13 Jul 2013 17:38:35 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPV00A3CQ09F480@HIDDEN>;
 Sat, 13 Jul 2013 17:38:33 +0300 (IDT)
Date: Sat, 13 Jul 2013 17:38:31 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
In-reply-to: <51E15CA2.70600@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <83mwpq4ja0.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
 <83ehb45eli.fsf@HIDDEN> <51DFD6A1.4010904@HIDDEN> <837ggv6h5g.fsf@HIDDEN>
 <51E135B0.4@HIDDEN> <83sizi4qun.fsf@HIDDEN> <51E15CA2.70600@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sat, 13 Jul 2013 15:56:50 +0200
> From: martin rudalics <rudalics@HIDDEN>
> CC: 14825 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 13 Jul 2013 13:57:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 09:57:11 2013
Received: from localhost ([127.0.0.1]:52697 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Uy0Jy-0005ES-GP
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2013 09:57:11 -0400
Received: from mout.gmx.net ([212.227.17.22]:52058)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1Uy0Jr-0005Di-Aj
 for 14825 <at> debbugs.gnu.org; Sat, 13 Jul 2013 09:57:04 -0400
Received: from [62.47.40.205] ([62.47.40.205]) by mail.gmx.com (mrgmx002) with
 ESMTPA (Nemesis) id 0MLfH9-1UyHZD0kx1-000tol;
 Sat, 13 Jul 2013 15:56:56 +0200
Message-ID: <51E15CA2.70600@HIDDEN>
Date: Sat, 13 Jul 2013 15:56:50 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
 <83ehb45eli.fsf@HIDDEN> <51DFD6A1.4010904@HIDDEN> <837ggv6h5g.fsf@HIDDEN>
 <51E135B0.4@HIDDEN> <83sizi4qun.fsf@HIDDEN>
In-Reply-To: <83sizi4qun.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:RLb8E4iG3LF4JebDfnGIQ7RjCZQ9wbSfTBbcg91Gf1l9SmSJS9q
 7rVlh/soY7ybCUVke6DcyY8PMPehOo8kWANuXTZCaEZHElbmepOYfWeU4dresxElQ9naiVQ
 zX0Is1un+uNJ36b4yM+6HEGcV7nFq662uGW5f8BdHh631/p74iGoPRbDZPJvtkJS4az4pih
 EIXwAGatQ5rh2TRhf0E2Q==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 13 Jul 2013 11:55:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 07:55:24 2013
Received: from localhost ([127.0.0.1]:52155 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UxyQ6-0000P0-2C
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2013 07:55:22 -0400
Received: from mtaout23.012.net.il ([80.179.55.175]:40738)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1UxyQ0-0000OO-Fs
 for 14825 <at> debbugs.gnu.org; Sat, 13 Jul 2013 07:55:18 -0400
Received: from conversion-daemon.a-mtaout23.012.net.il by
 a-mtaout23.012.net.il (HyperSendmail v2007.08) id
 <0MPV00B00IF7H600@HIDDEN> for 14825 <at> debbugs.gnu.org;
 Sat, 13 Jul 2013 14:54:59 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPV00BS5IFMBY60@HIDDEN>;
 Sat, 13 Jul 2013 14:54:59 +0300 (IDT)
Date: Sat, 13 Jul 2013 14:54:56 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
In-reply-to: <51E135B0.4@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <83sizi4qun.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
 <83ehb45eli.fsf@HIDDEN> <51DFD6A1.4010904@HIDDEN> <837ggv6h5g.fsf@HIDDEN>
 <51E135B0.4@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sat, 13 Jul 2013 13:10:40 +0200
> From: martin rudalics <rudalics@HIDDEN>
> CC: 14825 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 13 Jul 2013 11:11:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 07:11:01 2013
Received: from localhost ([127.0.0.1]:52093 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Uxxj9-00067X-Lt
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2013 07:11:00 -0400
Received: from mout.gmx.net ([212.227.15.18]:56096)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1Uxxj4-00067C-2K
 for 14825 <at> debbugs.gnu.org; Sat, 13 Jul 2013 07:10:55 -0400
Received: from [62.47.48.184] ([62.47.48.184]) by mail.gmx.com (mrgmx003) with
 ESMTPA (Nemesis) id 0MD9J6-1UwoaP1qA8-00GV0y;
 Sat, 13 Jul 2013 13:10:45 +0200
Message-ID: <51E135B0.4@HIDDEN>
Date: Sat, 13 Jul 2013 13:10:40 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
 <83ehb45eli.fsf@HIDDEN> <51DFD6A1.4010904@HIDDEN> <837ggv6h5g.fsf@HIDDEN>
In-Reply-To: <837ggv6h5g.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:PgL7obSn4wZ4YLSfUP9hZOnrZT/Kqi0MYut83jYMpvXrWfsSNU2
 s5KWsVR7eIaJ6Fh5MFVk2093JRL9tYcvSVvGiyifYPSYTqCLj9m2YQ0HdqOtzgu7yzc57Sv
 K52TG5jZmalbANNyNVpAJaLCRJm4Wv6BcLKw0jLG0RIr3sHdlj5qbIF5YiQN5syvgOY025X
 WNZ8O6ZwYSJyHDBXCTMaw==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 12 Jul 2013 14:58:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 10:58:30 2013
Received: from localhost ([127.0.0.1]:50535 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Uxenm-0003dz-5m
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2013 10:58:30 -0400
Received: from mail-ee0-f51.google.com ([74.125.83.51]:56884)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <lekktu@HIDDEN>) id 1Uxenk-0003da-HU
 for 14825 <at> debbugs.gnu.org; Fri, 12 Jul 2013 10:58:29 -0400
Received: by mail-ee0-f51.google.com with SMTP id e52so6278517eek.24
 for <14825 <at> debbugs.gnu.org>; Fri, 12 Jul 2013 07:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc:content-type;
 bh=uw2aZf/7AFGncd8EsYlwLepqo/c/FsrHthjagIEVnfU=;
 b=djZQyS/1lXzDWs6HsSTya8m4F3BGhMeClG7SmovLLoYPGK/11TUlltbTiSH6hnv4ln
 arXyV61n8KbhOEuo770F9qfI9/7xxpG8qyhB/U6Nozjc0Dkm+os7G3WWpMjjEZmv9EWE
 VNE0p9G5KZv6BJhSQj3sJDo7MP5xtiR781sIjOuij4tWslNTzb+fZ0OgQ8I1+RbkZs1a
 +SYiUeoSiXe6fvpIU4OZhnXzMueBosXZL/KqK8qQ1IOC+wQ3dJ79K9klmFBj9vyqmKZp
 QUWBWSZQ60xz4qy59QUc9ENo0Rs2CKAY2YHBhAWukMEAw76Zq7MK/mMB6Wd+G58UgdW9
 tkcQ==
X-Received: by 10.14.213.135 with SMTP id a7mr46996392eep.152.1373641102543;
 Fri, 12 Jul 2013 07:58:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.142.4 with HTTP; Fri, 12 Jul 2013 07:57:42 -0700 (PDT)
In-Reply-To: <837ggv6h5g.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
 <83ehb45eli.fsf@HIDDEN> <51DFD6A1.4010904@HIDDEN> <837ggv6h5g.fsf@HIDDEN>
From: Juanma Barranquero <lekktu@HIDDEN>
Date: Fri, 12 Jul 2013 16:57:42 +0200
Message-ID: <CAAeL0SRWfLxCrBub+4YKTBDurb2qHRmTzRz7FgV1V9avq63W0g@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 14825
Cc: martin rudalics <rudalics@HIDDEN>, 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

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

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

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

  J




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 12 Jul 2013 13:30:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 09:30:06 2013
Received: from localhost ([127.0.0.1]:50035 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UxdQB-0000hW-Sr
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2013 09:30:05 -0400
Received: from mtaout23.012.net.il ([80.179.55.175]:55277)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1UxdQ6-0000gr-Rt
 for 14825 <at> debbugs.gnu.org; Fri, 12 Jul 2013 09:30:00 -0400
Received: from conversion-daemon.a-mtaout23.012.net.il by
 a-mtaout23.012.net.il (HyperSendmail v2007.08) id
 <0MPT00400RWINS00@HIDDEN> for 14825 <at> debbugs.gnu.org;
 Fri, 12 Jul 2013 16:29:20 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPT004JVS4VHR80@HIDDEN>;
 Fri, 12 Jul 2013 16:29:20 +0300 (IDT)
Date: Fri, 12 Jul 2013 16:29:15 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
In-reply-to: <51DFD6A1.4010904@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <837ggv6h5g.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
 <83ehb45eli.fsf@HIDDEN> <51DFD6A1.4010904@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Fri, 12 Jul 2013 12:12:49 +0200
> From: martin rudalics <rudalics@HIDDEN>
> CC: 14825 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 12 Jul 2013 10:13:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 06:13:05 2013
Received: from localhost ([127.0.0.1]:49664 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UxaLY-0000JD-2i
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2013 06:13:04 -0400
Received: from mout.gmx.net ([212.227.17.20]:64244)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1UxaLV-0000IW-9Z
 for 14825 <at> debbugs.gnu.org; Fri, 12 Jul 2013 06:13:02 -0400
Received: from [62.47.41.10] ([62.47.41.10]) by mail.gmx.com (mrgmx002) with
 ESMTPA (Nemesis) id 0Lxxw4-1U9tWz0VAC-015IVU; Fri, 12 Jul 2013 12:12:53 +0200
Message-ID: <51DFD6A1.4010904@HIDDEN>
Date: Fri, 12 Jul 2013 12:12:49 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
 <83ehb45eli.fsf@HIDDEN>
In-Reply-To: <83ehb45eli.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:KcIoFgS7uiAMm9tXpJkgkKmsZ4C/gF3MMxL12JXmqqkV4Ud/dT6
 vtT5TQORm4vIA9RE33qDmyO28CWiqDeyIE9Y7ArMgw5fR2/alQUxCB8DAWE3LIozhjedD9C
 8MI2KXAQ7jLtIWY0N2ci/j9BoVKq3qv1fy1lIXJ2k3Aec/zobQ7YH1762z6oGLnyBessSZ7
 425HrkFKt7gpz1ZBL3Drg==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

 > 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 12 Jul 2013 09:10:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 05:10:17 2013
Received: from localhost ([127.0.0.1]:49617 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UxZMm-0006Hf-16
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2013 05:10:16 -0400
Received: from mtaout20.012.net.il ([80.179.55.166]:50926)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1UxZMj-0006Gy-5N
 for 14825 <at> debbugs.gnu.org; Fri, 12 Jul 2013 05:10:14 -0400
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0MPT00H00FZVSM00@HIDDEN> for 14825 <at> debbugs.gnu.org;
 Fri, 12 Jul 2013 12:09:51 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPT00H7MG4EVA00@HIDDEN>;
 Fri, 12 Jul 2013 12:09:51 +0300 (IDT)
Date: Fri, 12 Jul 2013 12:09:45 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
In-reply-to: <51DFBC95.5040207@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <83ehb45eli.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN> <51DFBC95.5040207@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 12 Jul 2013 08:21:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 04:21:54 2013
Received: from localhost ([127.0.0.1]:49490 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UxYbx-00045l-Qq
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2013 04:21:54 -0400
Received: from mout.gmx.net ([212.227.15.18]:50272)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1UxYbw-00045U-8L
 for 14825 <at> debbugs.gnu.org; Fri, 12 Jul 2013 04:21:52 -0400
Received: from [62.47.40.146] ([62.47.40.146]) by mail.gmx.com (mrgmx103) with
 ESMTPA (Nemesis) id 0MWCKz-1UhtRI1AUL-00XM4O;
 Fri, 12 Jul 2013 10:21:45 +0200
Message-ID: <51DFBC95.5040207@HIDDEN>
Date: Fri, 12 Jul 2013 10:21:41 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN> <834nc1uji4.fsf@HIDDEN>
In-Reply-To: <834nc1uji4.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:23AHks2gP7tQ1WPVSE8tFpVwQHOnFiWmJvafu6JUgsq6ZlVmUQh
 rMa9OLJiDD8waYMIYLulJ8ZC74THaMAfH7POBufTGnHL6iMpR8FWQRkidw4S3LHg7WFSieT
 fPkPaFTTfndkfsPc/pKKhK3VdcuUJ83WiCAY9anGnnNljbQEMFUQF6sY0QkGLmVOBPpHLAL
 mCgcMshVySvh5huCVJndA==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

 > 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 11 Jul 2013 16:52:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 11 12:52:38 2013
Received: from localhost ([127.0.0.1]:48241 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UxK6f-00042K-49
	for submit <at> debbugs.gnu.org; Thu, 11 Jul 2013 12:52:37 -0400
Received: from mtaout23.012.net.il ([80.179.55.175]:33075)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1UxK6c-000420-Da
 for 14825 <at> debbugs.gnu.org; Thu, 11 Jul 2013 12:52:35 -0400
Received: from conversion-daemon.a-mtaout23.012.net.il by
 a-mtaout23.012.net.il (HyperSendmail v2007.08) id
 <0MPS00L006QB2W00@HIDDEN> for 14825 <at> debbugs.gnu.org;
 Thu, 11 Jul 2013 19:52:27 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPS00K606VEV9A0@HIDDEN>;
 Thu, 11 Jul 2013 19:52:27 +0300 (IDT)
Date: Thu, 11 Jul 2013 19:52:19 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
In-reply-to: <51DE504E.2010804@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <834nc1uji4.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
 <51DE504E.2010804@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Thu, 11 Jul 2013 08:27:26 +0200
> From: martin rudalics <rudalics@HIDDEN>
> CC: 14825 <at> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 11 Jul 2013 06:27:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 11 02:27:42 2013
Received: from localhost ([127.0.0.1]:46729 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UxALt-0003KR-2i
	for submit <at> debbugs.gnu.org; Thu, 11 Jul 2013 02:27:41 -0400
Received: from mout.gmx.net ([212.227.15.18]:56246)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1UxALo-0003K3-NY
 for 14825 <at> debbugs.gnu.org; Thu, 11 Jul 2013 02:27:38 -0400
Received: from [62.47.49.106] ([62.47.49.106]) by mail.gmx.com (mrgmx102) with
 ESMTPA (Nemesis) id 0MXmpv-1UiY100C9P-00WoN6;
 Thu, 11 Jul 2013 08:27:29 +0200
Message-ID: <51DE504E.2010804@HIDDEN>
Date: Thu, 11 Jul 2013 08:27:26 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN> <83obaav2ug.fsf@HIDDEN>
In-Reply-To: <83obaav2ug.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:yZH4AR00ugi6123mNYOm8RdM0EQTjUNcFNCsSeP9LA4Ay6JJq47
 yS/2/KmHCO2Fo/Zw2dyO0gIv6mcLxCdoMjrIOs1ZXdvwfiIryx2kWB3qPhNPkOomlWfbOd9
 O5rwEDAmz0y4B2LCYKWiE6jUr/Hy3tvBLD8TdjVqg5xRu74PgNdgz/s3FvFdUG+jI6DiVRm
 sq6gp2HDqCZdmI2FA3APA==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 10 Jul 2013 15:42:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 10 11:42:41 2013
Received: from localhost ([127.0.0.1]:45496 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UwwXQ-0007GF-6S
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2013 11:42:40 -0400
Received: from mtaout22.012.net.il ([80.179.55.172]:44000)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1UwwXN-0007G2-Sj
 for 14825 <at> debbugs.gnu.org; Wed, 10 Jul 2013 11:42:39 -0400
Received: from conversion-daemon.a-mtaout22.012.net.il by
 a-mtaout22.012.net.il (HyperSendmail v2007.08) id
 <0MPQ002008U1E300@HIDDEN> for 14825 <at> debbugs.gnu.org;
 Wed, 10 Jul 2013 18:42:25 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPQ0027W8YODP20@HIDDEN>;
 Wed, 10 Jul 2013 18:42:25 +0300 (IDT)
Date: Wed, 10 Jul 2013 18:42:15 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
In-reply-to: <51DD0B31.8000901@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <83obaav2ug.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN> <51DD0B31.8000901@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Wed, 10 Jul 2013 09:20:17 +0200
> From: martin rudalics <rudalics@HIDDEN>
> CC: 14825 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 10 Jul 2013 07:20:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 10 03:20:39 2013
Received: from localhost ([127.0.0.1]:44117 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Uwohb-0002Ho-4I
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2013 03:20:39 -0400
Received: from mout.gmx.net ([212.227.15.18]:60002)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1UwohX-0002H3-F5
 for 14825 <at> debbugs.gnu.org; Wed, 10 Jul 2013 03:20:37 -0400
Received: from [62.47.61.1] ([62.47.61.1]) by mail.gmx.com (mrgmx003) with
 ESMTPA (Nemesis) id 0M7HGA-1U1ISb45vK-00x5vB; Wed, 10 Jul 2013 09:20:28 +0200
Message-ID: <51DD0B31.8000901@HIDDEN>
Date: Wed, 10 Jul 2013 09:20:17 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
 <83bo6bww40.fsf@HIDDEN>
In-Reply-To: <83bo6bww40.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:i85P2+R6WUl2d8Z51xYSpfI83ty9hNktcY6Dh9j7YrqUqWqvA+J
 ERO7NqoXd5NkE0Ft67IsvvxUaNHOQYeQuZ/kp8wGG416KbmzzEHerclrso/WJ+0EBLdUu2V
 qmHrnrSUehtcxIvJMus0Er5mXfgYZFY/o0SKMQQH5sq9A9ciPSE/sfWtPVO5ei+1wu6W6Rm
 OBbH+5g4AA7twNwStYzaA==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 9 Jul 2013 16:12:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 09 12:12:55 2013
Received: from localhost ([127.0.0.1]:42962 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UwaX7-0006Rq-Gs
	for submit <at> debbugs.gnu.org; Tue, 09 Jul 2013 12:12:53 -0400
Received: from mtaout20.012.net.il ([80.179.55.166]:35669)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1UwaX4-0006RS-Br
 for 14825 <at> debbugs.gnu.org; Tue, 09 Jul 2013 12:12:51 -0400
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0MPO00L00FNKWO00@HIDDEN> for 14825 <at> debbugs.gnu.org;
 Tue, 09 Jul 2013 19:12:43 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPO00L7PFP7Q670@HIDDEN>;
 Tue, 09 Jul 2013 19:12:43 +0300 (IDT)
Date: Tue, 09 Jul 2013 19:12:31 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
In-reply-to: <51DBD33D.4000307@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <83bo6bww40.fsf@HIDDEN>
References: <83hag5vszy.fsf@HIDDEN> <51DBD33D.4000307@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Tue, 09 Jul 2013 11:09:17 +0200
> From: martin rudalics <rudalics@HIDDEN>
> CC: 14825 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at 14825 <at> debbugs.gnu.org:


Received: (at 14825) by debbugs.gnu.org; 9 Jul 2013 09:09:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 09 05:09:37 2013
Received: from localhost ([127.0.0.1]:41281 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UwTvU-0008HG-LR
	for submit <at> debbugs.gnu.org; Tue, 09 Jul 2013 05:09:36 -0400
Received: from mout.gmx.net ([212.227.17.21]:62474)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1UwTvR-0008Gp-Q7
 for 14825 <at> debbugs.gnu.org; Tue, 09 Jul 2013 05:09:34 -0400
Received: from [62.47.46.161] ([62.47.46.161]) by mail.gmx.com (mrgmx003) with
 ESMTPA (Nemesis) id 0MFMEG-1V20FF43cK-00EJEe;
 Tue, 09 Jul 2013 11:09:26 +0200
Message-ID: <51DBD33D.4000307@HIDDEN>
Date: Tue, 09 Jul 2013 11:09:17 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
References: <83hag5vszy.fsf@HIDDEN>
In-Reply-To: <83hag5vszy.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:m1Xqju7cCNwvK/ZaA+bHpuJezRtNhRDYxkTN7puIMPqoJL3kNlh
 gGJ0IBns0OGdgPdEyOOMHmrhFQ78BtTthGl+r/ZD2+kUa9Xg/rKqBIsTUQyRLEspiGIrr7K
 +A8yMm0zEi3r1vM24ioIO6WUCilHdIUeFAyBbMpSY0c5M1FweQa8BZQL4jj9sh+cT+bsjJF
 KfPDgr/zs7eM0k/o79w0w==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 14825
Cc: 14825 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

 > 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 8 Jul 2013 17:53:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 08 13:53:22 2013
Received: from localhost ([127.0.0.1]:39976 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1UwFcn-00040a-Dc
	for submit <at> debbugs.gnu.org; Mon, 08 Jul 2013 13:53:21 -0400
Received: from eggs.gnu.org ([208.118.235.92]:40446)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1UwFcl-00040G-Tw
 for submit <at> debbugs.gnu.org; Mon, 08 Jul 2013 13:53:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1UwFce-0004JH-DK
 for submit <at> debbugs.gnu.org; Mon, 08 Jul 2013 13:53:14 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-99.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD,
 USER_IN_WHITELIST autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:54963)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1UwFce-0004JD-9L
 for submit <at> debbugs.gnu.org; Mon, 08 Jul 2013 13:53:12 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42137)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1UwFcb-0006K0-W2
 for bug-gnu-emacs@HIDDEN; Mon, 08 Jul 2013 13:53:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1UwFcX-0004Gc-MG
 for bug-gnu-emacs@HIDDEN; Mon, 08 Jul 2013 13:53:09 -0400
Received: from mtaout23.012.net.il ([80.179.55.175]:62636)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1UwFcX-0004GA-E9
 for bug-gnu-emacs@HIDDEN; Mon, 08 Jul 2013 13:53:05 -0400
Received: from conversion-daemon.a-mtaout23.012.net.il by
 a-mtaout23.012.net.il (HyperSendmail v2007.08) id
 <0MPM00E00PIB2P00@HIDDEN> for bug-gnu-emacs@HIDDEN;
 Mon, 08 Jul 2013 20:53:03 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MPM00EYLPOF0Y40@HIDDEN> for bug-gnu-emacs@HIDDEN;
 Mon, 08 Jul 2013 20:53:03 +0300 (IDT)
Date: Mon, 08 Jul 2013 20:52:49 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: 24.3.50; split-window-below miscounts window lines
X-012-Sender: halo1@HIDDEN
To: bug-gnu-emacs@HIDDEN
Message-id: <83hag5vszy.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: Solaris 10
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.3 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.3 (-----)

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@HIDDEN
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--




Acknowledgement sent to Eli Zaretskii <eliz@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#14825; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.