From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#23478: 25.0.93; Mouse region selection asymmetry Date: Mon, 04 Jul 2016 18:56:03 +0200 Message-ID: <87bn2d736k.fsf@gmx.net> References: <878tzky2oe.fsf@gmx.net> <83eg9cecy2.fsf@gnu.org> <87wpn4wgev.fsf@gmx.net> <8360uoe5ye.fsf@gnu.org> <87shxswd5s.fsf@gmx.net> <834ma8e3ll.fsf@gnu.org> <871t3bhbpz.fsf@users.sourceforge.net> <87poqun63w.fsf@gmx.net> <83furqratc.fsf@gnu.org> <87h9c6mkb0.fsf@gmx.net> <83vb0mp1ok.fsf@gnu.org> <87wpl17pvs.fsf@gmx.net> <83eg79pi29.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1467653129 23237 80.91.229.3 (4 Jul 2016 17:25:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2016 17:25:29 +0000 (UTC) Cc: 23478@debbugs.gnu.org, npostavs@users.sourceforge.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 04 19:25:18 2016 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 1bK7cT-0007Pw-RR for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jul 2016 19:25:18 +0200 Original-Received: from localhost ([::1]:49419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK7cT-0007KH-2m for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jul 2016 13:25:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK7BB-0005R4-Ge for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 12:57:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bK7B8-0004AN-Cu for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 12:57:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK7B8-0004AJ-9H for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 12:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bK7B8-0005Yk-1s for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 12:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jul 2016 16:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23478 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 23478-submit@debbugs.gnu.org id=B23478.146765138921329 (code B ref 23478); Mon, 04 Jul 2016 16:57:01 +0000 Original-Received: (at 23478) by debbugs.gnu.org; 4 Jul 2016 16:56:29 +0000 Original-Received: from localhost ([127.0.0.1]:37343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bK7Aa-0005Xx-QE for submit@debbugs.gnu.org; Mon, 04 Jul 2016 12:56:29 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:57321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bK7AY-0005Xk-N7 for 23478@debbugs.gnu.org; Mon, 04 Jul 2016 12:56:27 -0400 Original-Received: from rosalinde ([89.245.65.175]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lymoh-1bPHk101Sh-016AGf; Mon, 04 Jul 2016 18:56:06 +0200 In-Reply-To: <83eg79pi29.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 04 Jul 2016 17:57:18 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-Provags-ID: V03:K0:FDWNLcH78dwzYs5Dnyq+yyOyEpIBJ41OE/KyUV88XrjvDYVXVEH 5ROxvgtvtARhdkvdX2H3U+Sz18MQFp+Sf3ReqfV0zc1IpKlfyA22s9OfqLag2NcASfueyVY heRoOsycRGEAwvd7MjCJjHiSFrOHcKDubH5fLA2PSpBbyZBCpk9ftg5la4IlgbmZUahcSHT ATPBTBc5dlr5yKCd92nBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ukaG8Qn3I1g=:eD3BWGmSFSr12UrB4t/SNw cO84dZJWNQo7LjF8577NaoB7x06huog3ue82ifhfzIojNpzxDzK+qNagYNxvdSPurLZQ5bYUi XF8i76/rMV7JTEgyWxlb2GWsfTKWIkLWHbnPa2qQnBv74DsFGbPHD43F8zzXLj5H4+HB2nQYK Ngrqdt77Pn0YC9dEcSsghaJiyvGrUqqB58Pot7Q9DJlK2nuXjRMTdKY0j6xB+QjEKaSfvtIZW wtXoVzCj3ydyia13r+AV0Neade6P+FcGngLNvbRfilOCo3l8KjXJTlkqGKAZFaRXGaREsQn+h 7EXUyfK5fEqQioKt7vT1FCNHsMxl4MS3nF9q+DY+cr2uBjV8TQFUYZsrweDkQN04L+OHXuUak Rr/jrMLzpVnfGztdTBVQ9vdD2r2qCZlkHReo8xx1DVjHdEV0dPbJPWImyyjjwR//dNR4zpWWk Z7MMf9TBIKuTRtzazxuSaJKsD0MW2hqbbDVxrO+etCVlGrd+BXwoP3De0NokIzhg8BF+WbfPG kodZMx9RmipA3lvpXNkZfXm1aFrrRxUOhVLHJowo9yL84Lgy3LNwGRaxEBfAQvMdKcwbtYp2w Rrrwu990cBeNHBlRSsW/sO+jLly5QJhkvottTWN2/93Dn2ddFgDzsvM2ArtZlJ5U4+hOcYxjL zOnbTZlAJ80PR8DPXL7vGZcCgaHI9XoRXkEDVPSiZAE/3xr7QuLoGZIkVIseTWJBR0dDes/Dy 0ayLEPFHq5uJNiqlvj2812mJcVeucxOs/N4BoRQ6lmR/DSgDZnsJ6fYCuEjI6C6dCgbPoM5U X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:120413 Archived-At: On Mon, 04 Jul 2016 17:57:18 +0300 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: npostavs@users.sourceforge.net, 23478@debbugs.gnu.org >> Date: Mon, 04 Jul 2016 10:45:43 +0200 >> >> > Let's make one step back and describe the exact change in behavior >> > with the last patch, OK? Maybe some of us (e.g., me) don't really >> > understand what is the change. >> >> It simply makes selecting a region by double-clicking with the mouse >> more uniform; as I wrote in my OP, the current behavior is this: >> >> When you select a region by double-clicking with mouse-1 and the end >> of the region is below the last visible line of the window, Emacs >> recenters the display, making the entire selected region visible >> (unless it's larger than half the window's height). But when you >> select a region by double-clicking with mouse-1 and the beginning of >> the region is above the first visible line of the window, Emacs does >> not recenter the display, so the entire selected region is not >> visible. >> >> With the patch the behavior is now simply this: >> >> When you select a region by double-clicking with mouse-1, Emacs >> recenters the display, making the entire selected region visible >> (unless it's larger than half the window's height). >> >> To me (and I think Noam agrees), this is the behavior I would expect, >> while the current behavior is less user-friendly; I can't think of a >> reason why anyone would dislike the new behavior or prefer the current >> behavior, but maybe someone can provide a use case. > > Thanks, I wanted to be sure I understand the change correctly. > > This is indeed a change in behavior: the display recentering in the > second situation might be undesirable, since some text that was > previously visible might become invisible. But (more of) the text that is selected by mouse-click becomes visible; surely that's more desirable, don't you think? And again, that makes the second situation more like in the first situation, which also seems desirable. > And what will happen if > the region is larger than the window can show? Part of the region simply won't be displayed in the window, which is nothing new: the same thing that currently happens in the first situation. > In the first situation, the mouse click actually moves point, so the > scrolling that may follow is expected. Not so in the second case. Actually, it's easy to get this in the second situation: just call exchange-point-and-mark once: diff --git a/lisp/mouse.el b/lisp/mouse.el index 8d72753..39adc42 100644 --- a/lisp/mouse.el +++ b/lisp/mouse.el @@ -548,7 +548,11 @@ mouse-set-point (interactive "e\np") (mouse-minibuffer-check event) (if (and promote-to-region (> (event-click-count event) 1)) - (mouse-set-region event) + (progn + (mouse-set-region event) + (when (> (window-start) (region-beginning)) + (exchange-point-and-mark) + (sit-for 0))) ;; Use event-end in case called from mouse-drag-region. ;; If EVENT is a click, event-end and event-start give same value. (posn-set-point (event-end event)))) This makes the bevavior even more like the first situation (i.e., the mirror image of it). So I like this solution even better. What do you think? > So I still think we should default to the old behavior. Even with the above adjustment? Although three of the four opinions that have been voiced in this thread have been in favor of just having the new behavior (though that was prior to the above adjustment), I will defer to your decision, or if you wish, ask John to settle it. And to be clear, whatever the decision on a user option and concomitant default, I would rather install the above patch, where point moves, than the version where point does not move. Steve Berman