From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#7004: 23.2; In fullscreen mode, the echo area takes too much vertical space Date: Mon, 13 Sep 2010 20:59:27 +0200 Message-ID: <4C8E748F.5040107@swipnet.se> References: <4C89F3E3.6080804@swipnet.se> <4C8A3D5F.10502@swipnet.se> <4C8AC907.80102@harpegolden.net> <4C8B34C6.5060906@swipnet.se> <83r5gx4y6e.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1284405039 1935 80.91.229.12 (13 Sep 2010 19:10:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Sep 2010 19:10:39 +0000 (UTC) Cc: 7004@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 13 21:10:38 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OvEQH-0000f2-JJ for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Sep 2010 21:10:37 +0200 Original-Received: from localhost ([127.0.0.1]:59396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvEQG-0006de-Sk for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Sep 2010 15:10:36 -0400 Original-Received: from [140.186.70.92] (port=36402 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvEQ9-0006cs-Hy for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2010 15:10:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvEQ8-0005bh-AW for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2010 15:10:29 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58860) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvEQ8-0005bX-97 for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2010 15:10:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OvEE6-0006LN-3L; Mon, 13 Sep 2010 14:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2010 18:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7004 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7004-submit@debbugs.gnu.org id=B7004.128440424124377 (code B ref 7004); Mon, 13 Sep 2010 18:58:01 +0000 Original-Received: (at 7004) by debbugs.gnu.org; 13 Sep 2010 18:57:21 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvEDQ-0006L8-Jh for submit@debbugs.gnu.org; Mon, 13 Sep 2010 14:57:20 -0400 Original-Received: from smtprelay-h22.telenor.se ([195.54.99.197]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvEDO-0006L3-Kj for 7004@debbugs.gnu.org; Mon, 13 Sep 2010 14:57:19 -0400 Original-Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 37CBAE939C for <7004@debbugs.gnu.org>; Mon, 13 Sep 2010 20:59:29 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQ6AOgQjkxV4S0jPGdsb2JhbACDG4RSmV8MAQEBATUttBqRWIEigyp0BI0k X-IronPort-AV: E=Sophos;i="4.56,360,1280700000"; d="scan'208";a="1670525952" Original-Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb4.telenor.se with ESMTP; 13 Sep 2010 20:59:29 +0200 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 8F5487FA05A; Mon, 13 Sep 2010 20:59:28 +0200 (CEST) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 In-Reply-To: <83r5gx4y6e.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 13 Sep 2010 14:58:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:40138 Archived-At: Eli Zaretskii skrev 2010-09-13 14.37: >> Date: Sat, 11 Sep 2010 09:50:30 +0200 >> From: Jan Dj=C3=A4rv >> Cc: "7004@debbugs.gnu.org"<7004@debbugs.gnu.org> >> >> David De La Harpe Golden skrev 2010-09-11 02.10: >> >>> has support for displaying only part of a character line, at least at= the >>> bottom edge of a pane [emacs: window] (not sure about the top). It al= so >>> supports partial character display at the right/left edge of the pane= . > > That's right: Emacs does know how to display a partial line at the > bottom of a window (not at the top, though, IIRC). The question is > why doesn't it happen in the OP's case. > > Perhaps that is some unintended side effect of how a frame is > maximized on X (I cannot reproduce the problem on MS-Windows). What > happens if the frame is enlarged (e.g., by the mouse) instead? The resizing is constrained to increments of the font size, so it is not=20 possible to resize it manually to a fraction of the font size. If we remove that constraint by editing the source it will show the same=20 behavour, extra pixels are unused at the bottom of the frame. > >> Windows use code like this all over the place: >> >> /* Return the frame y-position before which window W ends. >> This includes a mode line, if any. */ >> >> #define WINDOW_BOTTOM_EDGE_Y(W) \ >> (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \ >> ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \ >> + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W)) >> >> >> i.e. pixels =3D lines * font height. > > No, your conclusion is incorrect. See the comment above this macro: > this is the Y pixel coordinate _before_ which the window ends. If the > last line is only partially visible, the this macro will return a > value that is beyond the actual window display area. > > IOW, the fact that Emacs counts pixels in increments of the frame's > default font size does not contradict the ability of displaying > partially visible lines at the window bottom. When I maximize a frame > on Windows, that is what I get: the last line is only partially > visible. Why doesn't this happen for the OP on X? I know it can dispay partial lines, info does that on its first page, for= =20 example, since the title is in a larger font. But I don't know of any function that sizes a window by pixels. All the=20 resizing code does is to calculate rows and columns from the pixel sizes = and=20 the call change_frame_size. That in turn resizes windows, but just based= on=20 lines and columns, not pixels AFAIK. I see that W32 does that also, so how can it be different? Jan D.