From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12419: Mouse click changes layout Date: Wed, 26 Sep 2012 10:22:02 +0200 Message-ID: <83ehlpgpn9.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1348647802 10120 80.91.229.3 (26 Sep 2012 08:23:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 08:23:22 +0000 (UTC) Cc: occitan@esperanto.org, 12419@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 26 10:23:27 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 1TGmtu-0005nk-EP for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 10:23:22 +0200 Original-Received: from localhost ([::1]:37180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGmtp-0000HI-FE for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 04:23:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:32877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGmtj-0000GQ-Rg for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 04:23:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGmtd-00014A-GK for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 04:23:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGmtd-000146-D2 for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 04:23:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGmta-0000XP-Br for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 04:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 08:23: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.13486477271996 (code B ref 12419); Wed, 26 Sep 2012 08:23:02 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 26 Sep 2012 08:22:07 +0000 Original-Received: from localhost ([127.0.0.1]:56293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGmsh-0000W9-5R for submit@debbugs.gnu.org; Wed, 26 Sep 2012 04:22:07 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58229) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGmsd-0000Vn-Nh for 12419@debbugs.gnu.org; Wed, 26 Sep 2012 04:22:05 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MAY00L006ZD2W00@a-mtaout23.012.net.il> for 12419@debbugs.gnu.org; Wed, 26 Sep 2012 10:22:04 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAY00K1878SZ5B0@a-mtaout23.012.net.il>; Wed, 26 Sep 2012 10:22:04 +0200 (IST) In-reply-to: <5061BBD7.8070009@gmx.at> X-012-Sender: halo1@inter.net.il 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:64907 Archived-At: > Date: Tue, 25 Sep 2012 16:12:39 +0200 > From: martin rudalics > CC: occitan@esperanto.org, 12419@debbugs.gnu.org >=20 > >> > Where in the code or the infrastructure do we enforce an int= egral > >> > number of lines in a window? > >> > >> All over the window handling code, presently. > > > > Can you humor me with a typical example, please? >=20 > The central routine is `window--resize-child-windows'. But > `balance-windows-2' and `fit-window-to-buffer' are typical too. Al= l > these go a long way to meet a self-imposed restriction specified in > lines (and columns) by adding lines one-by-one to some window. 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 a= nd 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; 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. 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 ri= ght 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. 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. > >> So even if we manage to provide really maximized frames, the wi= ndow > >> handling code will have to show most windows with fully visible > >> lines. > > > > See above: you cannot guarantee that. >=20 > My experience tells me that people using the default face and only = that > will ask for it. Let's hope I'm wrong. It happens already today: with some customizations of frame parameter= s the last line of a single-window frame is not fully visible already, albeit only slightly so. This happens since Emacs 21.1 introduced th= e 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-no= rmal-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. > > Do we really need such a change? What damage could be caused by > > accepting a window size in integral lines, but producing a windo= w that > > is slightly larger or smaller? Again, this happens today alread= y as > > long as non-default faces are displayed in the window. >=20 > Probably not much. Parts of the mouse code might report incongruen= t > results. Sorry, I don't follow: which mouse code did you have in mind, and why would it report incongruent results? > And likely, window resizing will get inconsistent over time. Again, please elaborate. > >> And I suppose that we want a function that calculates the numbe= r of > >> pixels between two buffer positions > > > > Doesn't pos-visible-in-window-p fit the bill already? >=20 > 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 val= ue > 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.