From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#14825: 24.3.50; split-window-below miscounts window lines Date: Sat, 13 Jul 2013 15:56:50 +0200 Message-ID: <51E15CA2.70600@gmx.at> References: <83hag5vszy.fsf@gnu.org> <51DBD33D.4000307@gmx.at> <83bo6bww40.fsf@gnu.org> <51DD0B31.8000901@gmx.at> <83obaav2ug.fsf@gnu.org> <51DE504E.2010804@gmx.at> <834nc1uji4.fsf@gnu.org> <51DFBC95.5040207@gmx.at> <83ehb45eli.fsf@gnu.org> <51DFD6A1.4010904@gmx.at> <837ggv6h5g.fsf@gnu.org> <51E135B0.4@gmx.at> <83sizi4qun.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1373723888 5830 80.91.229.3 (13 Jul 2013 13:58:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Jul 2013 13:58:08 +0000 (UTC) Cc: 14825@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 13 15:58:08 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uy0Kt-0007Lz-Ll for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2013 15:58:07 +0200 Original-Received: from localhost ([::1]:60789 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uy0Kt-0008HK-Co for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2013 09:58:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uy0Kq-0008H4-0S for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 09:58:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uy0Kp-0006CC-26 for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 09:58:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uy0Ko-0006C8-V1 for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 09:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Uy0Kn-0005Fi-Vc for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 09:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2013 13:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14825 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14825-submit@debbugs.gnu.org id=B14825.137372383120120 (code B ref 14825); Sat, 13 Jul 2013 13:58:01 +0000 Original-Received: (at 14825) by debbugs.gnu.org; 13 Jul 2013 13:57:11 +0000 Original-Received: from localhost ([127.0.0.1]:52697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uy0Jy-0005ES-GP for submit@debbugs.gnu.org; Sat, 13 Jul 2013 09:57:11 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:52058) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uy0Jr-0005Di-Aj for 14825@debbugs.gnu.org; Sat, 13 Jul 2013 09:57:04 -0400 Original-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 In-Reply-To: <83sizi4qun.fsf@gnu.org> X-Provags-ID: V03:K0:RLb8E4iG3LF4JebDfnGIQ7RjCZQ9wbSfTBbcg91Gf1l9SmSJS9q 7rVlh/soY7ybCUVke6DcyY8PMPehOo8kWANuXTZCaEZHElbmepOYfWeU4dresxElQ9naiVQ zX0Is1un+uNJ36b4yM+6HEGcV7nFq662uGW5f8BdHh631/p74iGoPRbDZPJvtkJS4az4pih EIXwAGatQ5rh2TRhf0E2Q== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76327 Archived-At: >> 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