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 13:10:40 +0200 Message-ID: <51E135B0.4@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> 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 1373713869 13436 80.91.229.3 (13 Jul 2013 11:11:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Jul 2013 11:11:09 +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 13:11:10 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 1UxxjJ-0002oc-5k for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2013 13:11:09 +0200 Original-Received: from localhost ([::1]:43140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxxjI-0004CM-Mh for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2013 07:11:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxxjE-0004C6-Fq for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 07:11:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxxjD-0003cF-Au for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 07:11:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxxjD-0003c0-84 for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 07:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UxxjC-00067u-4f for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2013 07:11: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 11:11:02 +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.137371386123544 (code B ref 14825); Sat, 13 Jul 2013 11:11:02 +0000 Original-Received: (at 14825) by debbugs.gnu.org; 13 Jul 2013 11:11:01 +0000 Original-Received: from localhost ([127.0.0.1]:52093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uxxj9-00067X-Lt for submit@debbugs.gnu.org; Sat, 13 Jul 2013 07:11:00 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:56096) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uxxj4-00067C-2K for 14825@debbugs.gnu.org; Sat, 13 Jul 2013 07:10:55 -0400 Original-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 In-Reply-To: <837ggv6h5g.fsf@gnu.org> X-Provags-ID: V03:K0:PgL7obSn4wZ4YLSfUP9hZOnrZT/Kqi0MYut83jYMpvXrWfsSNU2 s5KWsVR7eIaJ6Fh5MFVk2093JRL9tYcvSVvGiyifYPSYTqCLj9m2YQ0HdqOtzgu7yzc57Sv K52TG5jZmalbANNyNVpAJaLCRJm4Wv6BcLKw0jLG0RIr3sHdlj5qbIF5YiQN5syvgOY025X WNZ8O6ZwYSJyHDBXCTMaw== 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:76320 Archived-At: > ??? 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