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#7004: 23.2; In fullscreen mode, the echo area takes too much vertical space Date: Wed, 15 Sep 2010 09:00:25 +0200 Message-ID: <4C906F09.2030809@gmx.at> References: <4C89F3E3.6080804@swipnet.se> <4C8A3D5F.10502@swipnet.se> <4C8AC907.80102@harpegolden.net> <4C8B34C6.5060906@swipnet.se> <83r5gx4y6e.fsf@gnu.org> <4C8E748F.5040107@swipnet.se> <83aanl4fm3.fsf@gnu.org> <4C8E8E3B.7010305@swipnet.se> <831v8x49p3.fsf@gnu.org> <4C8F1E31.8030904@gmx.at> <83vd682puw.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1284534649 31862 80.91.229.12 (15 Sep 2010 07:10:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 15 Sep 2010 07:10:49 +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 Wed Sep 15 09:10:46 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 1Ovm8g-0000IM-K6 for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 Sep 2010 09:10:42 +0200 Original-Received: from localhost ([127.0.0.1]:47694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ovm8f-0004SG-NC for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 Sep 2010 03:10:41 -0400 Original-Received: from [140.186.70.92] (port=46997 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ovm8Y-0004SA-Pf for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2010 03:10:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ovm8X-0004UK-DR for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2010 03:10:34 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56101) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ovm8X-0004UG-C2 for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2010 03:10:33 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OvlxO-0007fk-1I; Wed, 15 Sep 2010 02:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Sep 2010 06:59: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.128453390229482 (code B ref 7004); Wed, 15 Sep 2010 06:59:01 +0000 Original-Received: (at 7004) by debbugs.gnu.org; 15 Sep 2010 06:58:22 +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 1Ovlwj-0007fT-He for submit@debbugs.gnu.org; Wed, 15 Sep 2010 02:58:21 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Ovlwg-0007fN-UA for 7004@debbugs.gnu.org; Wed, 15 Sep 2010 02:58:20 -0400 Original-Received: (qmail invoked by alias); 15 Sep 2010 07:00:33 -0000 Original-Received: from 62-47-51-5.adsl.highway.telekom.at (EHLO [62.47.51.5]) [62.47.51.5] by mail.gmx.net (mp047) with SMTP; 15 Sep 2010 09:00:33 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18ArsI35CoAlrRuxvFNwlIaS8o8/8Opua9rpiQoeu 3j1LXYjGYWp0VA User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <83vd682puw.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 15 Sep 2010 02:59: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:40174 Archived-At: >> (1) Pixel-to-character conversion routines. >> >> (2) Pixel-wise mouse tracking and coordinates_in_window stuff. >> >> (3) Pixel-wise window-configurations storing and comparing. > > Maybe I don't understand something, but all these are already in place > (perhaps with the exception of no. 3). Note that I'm not talking > about being able to set a window height to any number of pixels, just > waste less space in the mini-window, ... You have to be able to set a window height to any number of pixels if you want to fix the bug. The case at hand is when Emacs gets a request from the window manager to set the frame height to a value that is _not_ an integer multiple of Emacs' canonical line height (aka default font height) of that frame. IIUC Emacs usually refuses to do that but rounds the height to the nearest integer multiple of the canonical line height instead. For the maximize-frame case, however, Emacs does try to satisfy the request but adds the remainder of the rounding operation to the minibuffer window which gives a strange effect because we are accustomed to see the latter as a one line window without mode-/header-line. So let's assume that we want to move this remainder to the frame root window instead. Now coordinates_in_window from window.c has to "Test if the character at column *X, row *Y is within window W. If it is not, return ON_NOTHING; if it is in the window's text area, set *x and *y to its location relative to the upper left corner of the window, and return ON_TEXT; if it is on the window's modeline, return ON_MODE_LINE; ..." but the tests it performs is currently based on things like WINDOW_BOTTOM_EDGE_Y which is defined as #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)) that is, an integer multiple of the canonical line height of the frame of W. So this does not account for the remainder we want to add and the result could be that a mouse click in the window text area is recognized as a click on the window's modeline or even another window. Obviously, sampling windows for mouse-autoselection might give strange results as well. > which was the reason for this bug > report. ISTR that Jan and Yamamoto here discussed a similar problem for the horizontal case, that is, what to do with the remainder on the left or right of the scrollbar. martin