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#16013: 24.3.50; Rows in height is interpreted as pixels. Date: Thu, 16 Jan 2014 11:14:02 +0100 Message-ID: <52D7B0EA.4040704@gmx.at> References: <5579FC36-5F75-4679-87F6-048C5B7326F6@swipnet.se> <5299FD88.2090600@gmx.at> <529A33F4.5030606@swipnet.se> <529B0519.3010902@gmx.at> <529B1C71.9020707@gmx.at> <529CCE48.9090404@gmx.at> <529D8F3E.30400@gmx.at> <93EF122E-7EFC-4ACF-A216-E83981DD511A@swipnet.se> <529E2441.8030808@gmx.at> <9E083836-7DF3-4AC3-8711-A0E4757C9691@swipnet.se> <01BCA22D-62F2-4F04-B14C-85452A9D1201@swipnet.se> <52D14EA5.9060900@gmx.at> <52D18361.5050308@swipnet.se> <52D2663A.3020201@gmx.at> <52D7AE74.70302@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389867315 4329 80.91.229.3 (16 Jan 2014 10:15:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 10:15:15 +0000 (UTC) Cc: "16013@debbugs.gnu.org" <16013@debbugs.gnu.org> To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 16 11:15:21 2014 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 1W3jyr-0000p7-5v for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 11:15:21 +0100 Original-Received: from localhost ([::1]:59603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3jyq-0007x5-Og for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 05:15:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3jyg-0007wn-7D for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 05:15:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3jyY-0005Vj-TI for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 05:15:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3jyY-0005VW-Pb for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 05:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3jyX-0000JA-Re for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 05:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jan 2014 10:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16013 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16013-submit@debbugs.gnu.org id=B16013.13898672561105 (code B ref 16013); Thu, 16 Jan 2014 10:15:01 +0000 Original-Received: (at 16013) by debbugs.gnu.org; 16 Jan 2014 10:14:16 +0000 Original-Received: from localhost ([127.0.0.1]:52849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3jxn-0000Hk-UZ for submit@debbugs.gnu.org; Thu, 16 Jan 2014 05:14:16 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:54016) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3jxm-0000Hd-Aa for 16013@debbugs.gnu.org; Thu, 16 Jan 2014 05:14:15 -0500 Original-Received: from [62.47.53.191] ([62.47.53.191]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LvVYZ-1VKoju2XEB-010a2j for <16013@debbugs.gnu.org>; Thu, 16 Jan 2014 11:14:13 +0100 In-Reply-To: <52D7AE74.70302@gmx.at> X-Provags-ID: V03:K0:aZCaDMN/LLbnVxE3JPIoeSarvpH9Lg7RyCJBtvE9iaNryg3/edi Ks+wg1m/5aastIZ6IJaznZvzj6tVoRB1DXDRp/3x1Jwma7cINZiT/EOiEKedgFtp1WFJkwp PDHwQ8eJguNHeOdOFZfGAL53C41MTO+hc/8bGYhYVWiw9J2KEtrxcvR5cH9EppCBl8+tITV 7cf9QD3Px2GN33KhoIm8A== 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:83583 Archived-At: Sorry - my last mail contained unrelated text at the beginning. Stripped now for better reading: >> I frequently asked on this list what `frame-height' and especially the >> "number of lines available for display" stands for, but never got an >> answer I could understand. > > > This has been inconsistent historically, i.e. Lucid/Motif/No toolkit counts differently than Gtk/NS. > I think the Gtk count makes more sense. If a user requests 50 lines he probably means 50 editable lines, not 47. So I think we should not count tool bar or menu bar. > The documentation says > "The height of the frame contents, in characters." > I don't think menu and tool bar is content. I'm not sure what to do. There's no problem for most elements of `default-frame-alist' or when setting the default font. The only real offender is that of your init file - namely setting the default height. A trivial scenario for Emacs 24.3 on Windows (I didn't try with that version on Lucid/Motif but I suppose it's similar) is with emacs -Q: (setq default-frame-alist '((height . 50))) C-x 5 2 (set-frame-parameter nil 'height 50) This changes the height of the new frame although it apparently is already 50 lines high. Such behavior constitutes a bug IMHO. This could be fixed but is certainly not trivial enough for inclusion in 24.4. There are a few more arguments to count differently on Lucid/Motif/No toolkit/Windows: (1) When the window manager asks us to resize a frame, we do not subtract the toolbar height. That is, the height of the toolbar is included in the frame's text height afterwards, defeating our illusion that it's counted separately. This means an even less trivial fix than the one mentioned above. (2) The real height of the toolbar is with tool_bar_height which might not fit the one we assume (in x_figure_window_size) anyway. One more non-trivial fix since tool_bar_height is not available initially but only after the display engine handled it. But the display engine wants the initial height of the frame so we have a chicken-and-egg problem here. (3) Lucid/Motif/No toolkit/Windows can wrap the toolbar (something Gtk doesn't). The display engine does this by stealing the necessary height from the editing area - that is, the root window - and autonomously updating the `tool-bar-lines' frame parameter. This complicates subsequent frame resizing since we don't know a priori whether the toolbar will wrap again. So while I agree with you that menu and tool bar should not be considered content, I see no easy way to work around this assumption on the systems in question. Suggestions welcome. martin