From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Pfeiffer Newsgroups: gmane.emacs.bugs Subject: bug#12419: Mouse click changes layout Date: Tue, 25 Sep 2012 00:20:31 +0200 Message-ID: <5060DCAF.9030106@t-online.de> 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> Reply-To: occitan@esperanto.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1348525278 23612 80.91.229.3 (24 Sep 2012 22:21:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2012 22:21: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 Tue Sep 25 00:21:19 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 1TGH1h-0006YE-LU for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2012 00:21:17 +0200 Original-Received: from localhost ([::1]:56947 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGH1c-00089r-QJ for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Sep 2012 18:21:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGH1Y-00088k-SP for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2012 18:21:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGH1W-0007QS-Sx for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2012 18:21:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGH1W-0007Py-Os for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2012 18:21:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGH3O-00066i-Dv for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2012 18:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Pfeiffer Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Sep 2012 22: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.134852535423433 (code B ref 12419); Mon, 24 Sep 2012 22:23:02 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 24 Sep 2012 22:22:34 +0000 Original-Received: from localhost ([127.0.0.1]:53849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGH2v-00065t-Va for submit@debbugs.gnu.org; Mon, 24 Sep 2012 18:22:34 -0400 Original-Received: from mailout06.t-online.de ([194.25.134.19]:36890) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGH2t-00065l-3E for 12419@debbugs.gnu.org; Mon, 24 Sep 2012 18:22:32 -0400 Original-Received: from fwd18.aul.t-online.de (fwd18.aul.t-online.de ) by mailout06.t-online.de with smtp id 1TGH0z-0002xZ-6C; Tue, 25 Sep 2012 00:20:33 +0200 Original-Received: from [192.168.178.34] (XdylPvZvZhlgJF8qxNP+qKAzLulkqbuUPBR2a1ppdT+Vyj79ciCozKALcrjwsf7wRs@[84.176.156.214]) by fwd18.t-online.de with esmtp id 1TGH0x-0lBGHA0; Tue, 25 Sep 2012 00:20:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 In-Reply-To: <50601715.6030108@gmx.at> X-ID: XdylPvZvZhlgJF8qxNP+qKAzLulkqbuUPBR2a1ppdT+Vyj79ciCozKALcrjwsf7wRs X-TOI-MSGID: 81e0b1b9-694e-4937-978e-78a406798348 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:64858 Archived-At: Hi Martin! la 09/24/2012 10:17 AM martin rudalics skribis: > > However my first informatics lesson the professor told us: the most > > common bug is being off by one. That is alas still the case with your > > patch: After C-x 2 the lower window is one row higher than the upper > > one. After our little experiment, it's the other way round, with this > > result: When letting go of the mouse, I still marked to the line above, > > which is now in the position of my mouse-down event. Sounds like an > > integer division rounding problem, though I don't see such a thing in > > your patch. If both windows together have an even number of rows (by > > resizing the frame) it's fine. > > You should get a similar behavior if you have a root window with an odd > number of lines, split that window via C-x 2, shrink the frame by one > line, and enlarge it again by one line: The upper window has stolen one > line from the lower one. As a matter of fact, this is not an off-by-one > error but more deeply rooted in the history of Emacs' window handling. > You can skip the following explanation if you want. > > Beginning with Emacs 24.1, windows have a normal height (a floating > point number) which is the fraction of their ideal height wrt to their > parent. When you do C-x 2 the normal height of both emanating windows > is 0.5. However, when the original window has an odd number of lines, > I have to give the lower window the one remaining line in order to be > consistent with the traditional splitting behavior. This means that, > if the original window has 11 lines, the upper window gets 5 and the > lower window gets 6 lines. > > If I now enlarge the parent window to 22 lines, the upper window gets > 11 (and not 10) lines and the lower window 11 (and not 12 lines). > Sizing back the parent to 11 lines should restore the initial state > but it doesn't because I resize windows in the "opposite" direction > (from top to bottom/from left to right) which preferably gives > to/steals from the topmost/leftmost window. > > So I have to fix this regardless of the topic we're discussing here. Good! Though it wouldn't annoy me so much, if it weren't that it slightly breaks your patch. What is important to me, is that when I click and let go, the point is where I initially clicked, and since I didn't move the mouse, I don't want to mark anything. As for going the "opposite" direction, I wonder if it's worth while to keep a history of the last n implicitly changed window configurations and try to revert to them wherever possible. Might be huge task admittedly... A somewhat related annoyance is that scrolling looses the point: scrolling back to where you were before, doesn't revert that. Whenever I scroll to somewhere, the point should go where it was last visible within those lines, if it had been visible there before! This should be quite straightforward. Though with sideways scrolling it might be more tricky... > > If however I split either of the two windows again (even the top one, > > which is out of reach of the resizing echo area) the disturbing new > > before-your-patch behaviour comes back. > > I suppose you should try again. If I split the top window, only the > bottom window resizes and I can't observe what you observe here. If I > make a new bottom window instead, the line where `point' appears in that > window moves to the top of the window and I can observe the behavior. > However, I don't see any difference wrt Emacs 23 which means I do not > see a "disturbing new" before-my-patch behavior. If you nevertheless > do, please give me a detailed step-by-step scenario I can repeat here. The "disturbing new" is that (in our C-x 2 scenario) by clicking somewhere, the point ends up somewhere else, and without moving the mouse I've marked some text. I'm fairly confident that this is a recent degradation. (Though I don't have an old Emacs to try against to be sure.) Your patch improved it, but not quite fixed it. > >> The second scenario you sketched is > [...] > > The point is moving the mouse over to the i, which causes the 1st > > scroll, and then letting go, which causes the scrolled region to be > > marked, plus it causes a 2nd scroll by the same amount. So the point is > > now far from the highlighted part. I guess this comes from a different > > code location. Only the user experience feels to me like both cases > > should be consistent with one another. > > OK. I see something in this regard. But Emacs 23 seems to behave in > exactly the same way. Or do you see a difference? I don't C-x 3 so much, so this might have been there before – I don't remember when it first annoyed me. Just the occasional glitch, which on its own never merited heckling anybody about. Actually sideways scrolling is only neat when I click near the edge wanting it. When I don't think about it, it's usually a hassle to get things like they were before. Probably it should only sideways scroll when I drag the mouse over the window edge, like vertical scrolling. coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn Daniel Pfeiffer -- lerne / learn / apprends / lär dig / ucz się Esperanto: http://lernu.net / http://ikurso.net