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 13:55:29 +0200 Message-ID: <83a9wdgfri.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> <83ehlpgpn9.fsf@gnu.org> <5062E0ED.3050901@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 1348660575 22849 80.91.229.3 (26 Sep 2012 11:56:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 11:56:15 +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 13:56:20 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 1TGqDx-0007LW-MM for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 13:56:17 +0200 Original-Received: from localhost ([::1]:34824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGqDs-0003T3-FR for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 07:56:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGqDo-0003Sy-UO for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:56:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGqDm-0002cf-9d for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:56:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGqDm-0002cK-5y for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:56:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGqDi-0006GV-C8 for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 07:56: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 11:56: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.134866053424049 (code B ref 12419); Wed, 26 Sep 2012 11:56:02 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 26 Sep 2012 11:55:34 +0000 Original-Received: from localhost ([127.0.0.1]:56424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGqDG-0006Fq-5K for submit@debbugs.gnu.org; Wed, 26 Sep 2012 07:55:34 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:47020) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGqDD-0006Fh-O5 for 12419@debbugs.gnu.org; Wed, 26 Sep 2012 07:55:33 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MAY00700H0E4H00@a-mtaout20.012.net.il> for 12419@debbugs.gnu.org; Wed, 26 Sep 2012 13:55:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAY006DTH4JRDB0@a-mtaout20.012.net.il>; Wed, 26 Sep 2012 13:55:31 +0200 (IST) In-reply-to: <5062E0ED.3050901@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:64916 Archived-At: > > 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 t= he right 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 e= ngine, > > AFAIK, that require an integral number of lines to be displayed = in a > > window. >=20 > I suppose so since otherwise we would have seen bugs earlier. A si= lly > question: Does the `display-engine' draw over a previous column/row= or > does it clip it? Sorry, I don't understand what you mean by "drawing over a previous column/row". Which "previous" column/row are we talking about? > > Sorry, I don't follow: which mouse code did you have in mind, an= d why > > would it report incongruent results? >=20 > Take make_lispy_position. It has >=20 > /* 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); >=20 > where >=20 > #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)) >=20 > 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 somet= hing? A window must always start with a fully-visible line (unless it's the only line), so in that sense a window always starts at an integral number of lines. But it doesn't have to _end_ with a fully-visible line. Does this explain why the above is not a problem? > >> And likely, window resizing will get inconsistent over time. > > > > Again, please elaborate. >=20 > 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. Can't happen: a window that displays 5.5 lines must have 6 lines, or else the glyphs for the last half-line will have no place in the glyp= h matrix. > 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? It's up to us. The easiest (and also the least surprising, IMO) woul= d be to resize from (5.5, 5.5) to (6.5, 4.5), i.e. by one full line. > >> 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. Th= at's > > not always required, or maybe I don't understand why you need a > > function that calculates the number of pixels between two positi= ons. >=20 > 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. I think pos-visible-in-window-p is what you need.