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 15:17:06 +0200 Message-ID: <838vbwhqjx.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> <83a9wdgfri.fsf@gnu.org> <5062F86A.4060502@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1348665498 1364 80.91.229.3 (26 Sep 2012 13:18:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 13:18:18 +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 15:18:23 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 1TGrVO-0002Zd-26 for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 15:18:22 +0200 Original-Received: from localhost ([::1]:52316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGrVI-00018v-RZ for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 09:18:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGrVD-00018h-3t for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 09:18:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGrV7-0002Y5-ET for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 09:18:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGrV7-0002Xx-Ai for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 09:18:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGrV5-00088L-4H for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 09:18:03 -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 13:18:03 +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.134866544831208 (code B ref 12419); Wed, 26 Sep 2012 13:18:03 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 26 Sep 2012 13:17:28 +0000 Original-Received: from localhost ([127.0.0.1]:56508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGrUV-00087I-Ji for submit@debbugs.gnu.org; Wed, 26 Sep 2012 09:17:28 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:33109) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGrUS-000875-0Z for 12419@debbugs.gnu.org; Wed, 26 Sep 2012 09:17:25 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MAY00700KUES500@a-mtaout20.012.net.il> for 12419@debbugs.gnu.org; Wed, 26 Sep 2012 15:17:08 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAY007DEKWKQY30@a-mtaout20.012.net.il>; Wed, 26 Sep 2012 15:17:08 +0200 (IST) In-reply-to: <5062F86A.4060502@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:64919 Archived-At: > Date: Wed, 26 Sep 2012 14:43:22 +0200 > From: martin rudalics > CC: occitan@esperanto.org, 12419@debbugs.gnu.org > > > Sorry, I don't understand what you mean by "drawing over a previous > > column/row". Which "previous" column/row are we talking about? > > For example, when we draw the mode-line of a window: Do we first clip > the glyphs on the bottom of the last proper line of the window or do we > draw them unclipped and afterwards draw the mode-line on top of it so it > obscures the lower part of the window line? It's the other way around: first the window is cleared, then we draw the mode line, and only then the window text. So the last line is already drawn only partially to begin with (I believe this is done by the display back-end, in *term.c, by clipping the drawn glyphs to the dimensions of the text area, but I'm not an expert on these back-ends). > >> 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 glyph > > matrix. > > Let's say the TTY equivalent of the upper window would display 5 lines. And the lower one 6, OK. > >> 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) would > > be to resize from (5.5, 5.5) to (6.5, 4.5), i.e. by one full line. > > In this case the TTY equivalent would display (6, 5) lines. Yes. Is that a problem? pos-visible-in-window-p can still tell whether the resize reached its goal of exposing the text you want, no? > >> 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. > > Currently it loops calling `pos-visible-in-window-p' until the position > is visible. How avoid that loop? I think the loop isn't needed for the application you have in mind. But if it is, can you show a concrete use case where just using that function gives bad results for measuring pixel distance between buffer positions?