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#12419: Mouse click changes layout Date: Wed, 26 Sep 2012 13:03:09 +0200 Message-ID: <5062E0ED.3050901@gmx.at> References: <504FB55D.5030405@t-online.de> <5050432C.4060203@gmx.at> <5052450F.8030001@t-online.de> <5052F242.4060303@gmx.at> <5055D769.1060804@t-online.de> <50561046.60902@gmx.at> <505E1FB6.1050504@t-online.de> <505ED4AB.7070009@gmx.at> <505F8576.8070902@t-online.de> <50601715.6030108@gmx.at> <833927jxrx.fsf@gnu.org> <5061802C.1070600@gmx.at> <834nmmi9sq.fsf@gnu.org> <5061BBD7.8070009@gmx.at> <83ehlpgpn9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1348657466 28372 80.91.229.3 (26 Sep 2012 11:04:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 11:04:26 +0000 (UTC) Cc: occitan@esperanto.org, 12419@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 26 13:04:31 2012 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 1TGpPm-0001Zn-FE for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 13:04:26 +0200 Original-Received: from localhost ([::1]:58037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGpPe-0005ko-FV for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 07:04:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGpPa-0005if-Um for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:04:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGpPQ-0007kb-OJ for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:04:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGpPQ-0007kW-KR for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:04:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGpPO-0004GL-6P for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 11:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12419-submit@debbugs.gnu.org id=B12419.134865739316315 (code B ref 12419); Wed, 26 Sep 2012 11:04:02 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 26 Sep 2012 11:03:13 +0000 Original-Received: from localhost ([127.0.0.1]:56404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGpOb-0004F5-Ag for submit@debbugs.gnu.org; Wed, 26 Sep 2012 07:03:13 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:39333) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGpOZ-0004Ex-Rl for 12419@debbugs.gnu.org; Wed, 26 Sep 2012 07:03:12 -0400 Original-Received: (qmail invoked by alias); 26 Sep 2012 11:03:12 -0000 Original-Received: from 62-47-47-61.adsl.highway.telekom.at (EHLO [62.47.47.61]) [62.47.47.61] by mail.gmx.net (mp027) with SMTP; 26 Sep 2012 13:03:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19Naz5Ej3FN75Pq3qP3o50LaptKhyx5BtOpjxa4dO WL6okunRcOecKw In-Reply-To: <83ehlpgpn9.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:64914 Archived-At: > That's true, but I don't think this is relevant to the issue. What > _is_ relevant is that these functions divide an odd number N of lines > in the window being split into an =E2=8C=88N/2=E2=8C=89-line window an= d an =E2=8C=8AN/2=E2=8C=8B-line > window, like an 11-line window being split into 6 and 5 lines. _This_= > is the self-imposed restriction we need to remove; Agreed. > what should happen > instead is that (in a GUI session) an N-line window is always split > into 2 =E2=8C=88N/2=E2=8C=89-line windows. =2E.. which can be partially truncated so we will have 2 =E2=8C=8AN/2=E2=8C= =8B-full-line windows. > The number of lines in a window is needed for the display engine to > allocate glyph matrices required to display the window. Having the > size of each child window at =E2=8C=88N/2=E2=8C=89 will ensure the rig= ht dimensions of > the glyph matrices, because even a partially-visible line needs a row > in the matrix. There are no other restrictions in the display engine,= > AFAIK, that require an integral number of lines to be displayed in a > window. I suppose so since otherwise we would have seen bugs earlier. A silly question: Does the `display-engine' draw over a previous column/row or does it clip it? > Note that on a TTY, there are no partially-visible lines, and the > window glyph matrices are just parts of a single frame-based matrix, > so the current way of dividing N lines should be kept for TTY. OK > It happens already today: with some customizations of frame parameters= > the last line of a single-window frame is not fully visible already, > albeit only slightly so. This happens since Emacs 21.1 introduced the= > special faces of the mode line, which take a few more pixels than a > normal text line in the default face. E.g., I have this in my .emacs:= > > (add-to-list 'default-frame-alist '(font . "-outline-Courier New-nor= mal-r-normal-normal-15-112-96-96-c-90-iso8859-1")) > (add-to-list 'default-frame-alist '(height . 50)) > > With these customizations, Emacs doesn't let me put the cursor on the > last line: it scrolls the window, because the last line is not > fully-visible. I don't think we've heard any complaints about this. I have '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-= width 2 :color "#000040") :weight bold :family "Verdana")))) which does similar things. In addition I use maximized frames which sometimes cover my entire display and sometimes don't. I suppose many people have learned to live with such shortcomings when they have customizations. But what about people who did not customize anything and= expect the old "integral lines" behavior. > Sorry, I don't follow: which mouse code did you have in mind, and why > would it report incongruent results? Take make_lispy_position. It has /* Pixel coordinates relative to the window corner. */ int wx =3D XINT (x) - WINDOW_LEFT_EDGE_X (w); int wy =3D XINT (y) - WINDOW_TOP_EDGE_Y (w); where #define WINDOW_TOP_EDGE_Y(W) \ (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \ ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \ + WINDOW_TOP_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W)) Now if the lower window of a two windows frame does not start at an integral number of lines this will not DTRT. Or am I missing something? >> And likely, window resizing will get inconsistent over time. > > Again, please elaborate. Consider a two window frame, the upper window has 5 lines the lower window has 6 lines but in fact both are shown with 5.5 lines. Now I enlarge the upper window by one line. Currently this makes a 6 to 5 lines frame. Would it make a 6.5 to 4.5 frame with the new code or a 6 to 5 lines frame? >> Have you looked at the loop at the end of `fit-window-to-buffer'? It= 's >> apparently needed because `count-screen-lines' doesn't return a value= >> that's good enough there. > > fit-window-to-buffer tries to avoid partially-visible lines. That's > not always required, or maybe I don't understand why you need a > function that calculates the number of pixels between two positions. For implementing something like `count-screen-lines-to-pixels' and get rid of that crazy loop where we calculate `pos-visible-in-window-p' and resize the window. martin