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: Wed, 06 Jul 2016 18:40:53 +0200 Message-ID: <87r3b6btyi.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> <87bn2d736k.fsf@gmx.net> <83furongms.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1467823347 13479 80.91.229.3 (6 Jul 2016 16:42:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2016 16:42:27 +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 Wed Jul 06 18:42:16 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 1bKptt-00087Y-TG for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jul 2016 18:42:14 +0200 Original-Received: from localhost ([::1]:34857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKptt-0005ow-4b for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jul 2016 12:42:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKptm-0005on-La for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 12:42:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKpti-0006K3-6i for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 12:42:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKpti-0006Jn-2c for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 12:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bKpth-00073r-P8 for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 12:42:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 16:42: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.146782327727091 (code B ref 23478); Wed, 06 Jul 2016 16:42:01 +0000 Original-Received: (at 23478) by debbugs.gnu.org; 6 Jul 2016 16:41:17 +0000 Original-Received: from localhost ([127.0.0.1]:39812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKpsy-00072t-NC for submit@debbugs.gnu.org; Wed, 06 Jul 2016 12:41:17 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:53786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKpsw-00072g-SQ for 23478@debbugs.gnu.org; Wed, 06 Jul 2016 12:41:15 -0400 Original-Received: from rosalinde ([89.245.89.122]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LiTrM-1bqsJO13Ii-00chQB; Wed, 06 Jul 2016 18:40:54 +0200 In-Reply-To: <83furongms.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 05 Jul 2016 20:23:23 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-Provags-ID: V03:K0:9RfZxyApevxVeuQXUMwE0GVdcTvTkNXr0F6LcVfK7HRtuABCI9w yLspLNhDLBjvUV5SX5Ox07kfm5sC9ROVkJRMOrfRHiO6JT7l8fjYKVUZKnRqVp5zuF6dyQ/ dEQRVLZRmThnn3kABBOXqGKkBRIgTRkQqba6ATFeFo504t+JzkZWItb4TlJRGIw/bRW0HC3 WJA0zfMgW4Pv/YePbcIKg== X-UI-Out-Filterresults: notjunk:1;V01:K0:KlodS1JBlVg=:n185Mvmoq3Kbh7yZ6MGqXN m4MfMGel3iaDN8iOaQkfXazG1JEOvMaPqSy7BV8Z14KVGqB+aqkfwOPIxil9gJpYSWpwO+TaY 45ZSE5S0zbpDdM69AhrnFWampjTyvlHoVLZKrSi3Dw70fovMsOCdX3RKgctys6ZNEZXCI6N/f Wnxfyuymx2hbTSknTYjJmDDM3tMQ6OGXg39kmZv4DMW3BuvpyUJxSjGmHg3w8nBLNe7EcwIoV /3BS5GbV/cA7bLP6Jb4kOvXzDdmluUSqu61DZAFVoaH768N/TYiSlxg1HwZBg3DoH4NXrUhzF TJ68SAoNAim6O9CVxFhu1QZkYTYrGNtHJEP06zQsfsWOQb5CsiyVbErG8uRXRMznQyXcYTR3x 4DJ8N3nsSgWg4ILZiVoPfGkZbqOL8fvrOw6Y0NjvV4z27LtSSWeohnepFE1zlRCEfkdWo3OND c4oz0tKsdZ3Nq721TyNcD/eCLCcjTjVDQaEKCJbjnvSZGFP7NVjR+pK4nbZu7JVzWsEssM6RF ABVT1Cg7h6TxJ2A1o2H+5p8d4qkpPHN+CjS0tY8bpZKIEL2jNeoy4oygYgBH4TCcLRXTLjI9z TkaUYdEZ64ELK808wM0yJGibmRccAqNuIr7zo92WENlhg5nY+CGYG+KOUfarmwyAe1uoYAv0/ xnxy3D8i1IWRqlgm8Ppz1pKu76jb4uZ98bPDDScBU2f8ywt4bp5b0mTeXmdzLvABxDEdP2otl cZl64C/exWZZ/oPmcrGNrn3h4j4cpjVYdtlLlM71Fov4s1aOWrZ/KhE5ncHMoSVks3tXQiZI 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:120521 Archived-At: On Tue, 05 Jul 2016 20:23:23 +0300 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: npostavs@users.sourceforge.net, 23478@debbugs.gnu.org >> Date: Mon, 04 Jul 2016 18:56:03 +0200 >> >> > So I still think we should default to the old behavior. >> >> Even with the above adjustment? > > Yes. For me, the important part is that the age-old behavior will > change. We have no idea how many users will like it and how many > won't. In particular, the new behavior that moves point where it > previously didn't might annoy people who intend to type after the > click. Thus, my preference is to make this an opt-in change. Perhaps > with time, if we hear many users asking this to be the default, we > will reverse the default value. I want to be clear about exactly what the new behavior should be. Since the patch referred to by "the above adjustment" was faulty and I followed it with an improvement, I assume "the new behavior that moves point" refers to the latter patch. So the user option would specify the behavior when selecting a region which extends backward from point, providing a choice between (i) the current behavior (as default), which leaves point at the position of the click and does not scroll backward if the region extends above window-start; and (ii) the new behavior, which moves point to region-beginning, scrolling if the region extends above window-start (the new behavior is thus the mirror image of the current behavior when selecting a region which extends forward from point). Here is a patch implementing this: diff --git a/lisp/mouse.el b/lisp/mouse.el index 8d72753..2f9ff6b 100644 --- a/lisp/mouse.el +++ b/lisp/mouse.el @@ -540,15 +540,31 @@ mouse-drag-vertical-line (interactive "e") (mouse-drag-line start-event 'vertical)) +(defcustom mouse-select-region-backward nil + "Effect of selecting a region extending backward from double click. + +Nil means keep point at the position clicked (region end) and +don't scroll backward when the region extends above the top of +the window; non-nil means move point to region beginning, +scrolling when the region extends above the top of the window." + :version "26.1" + :type '(choice (const :tag "Keep point and don't scroll backward" nil) + (const :tag "Move point and scroll if needed" t))) + (defun mouse-set-point (event &optional promote-to-region) "Move point to the position clicked on with the mouse. This should be bound to a mouse click event type. -If PROMOTE-TO-REGION is non-nil and event is a multiple-click, -select the corresponding element around point." +If PROMOTE-TO-REGION is non-nil and event is a multiple-click, select +the corresponding element around point, with the resulting position of +point determined by `mouse-select-region-backward'." (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 mouse-select-region-backward + (when (> (posn-point (event-start event)) (region-beginning)) + (exchange-point-and-mark)))) ;; 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)))) But note that, prior to the patch in my previous post, what was under discussion as the new behavior was different: namely, scrolling if the region extends above window-start but leaving point at the position of the click. This is a sort of compromise between the current behavior and that in (ii), and it could be a third choice for the user option. Here is a patch for this alternative: diff --git a/lisp/mouse.el b/lisp/mouse.el index 8d72753..19b4804 100644 --- a/lisp/mouse.el +++ b/lisp/mouse.el @@ -540,15 +540,37 @@ mouse-drag-vertical-line (interactive "e") (mouse-drag-line start-event 'vertical)) +(defcustom mouse-select-region-backward nil + "Effect of selecting a region extending backward from double click. + +Nil means keep point at the position clicked (region end) and +don't scroll backward when the region extends above the top of +the window; `keep' means keep point at region end but scroll when +the region extends above the top of the window; `move' means move +point to region beginning, scrolling when the region extends +above the top of the window." + :version "26.1" + :type '(choice (const :tag "Keep point and don't scroll backward" nil) + (const :tag "Keep point and scroll if needed" keep) + (const :tag "Move point and scroll if needed" move))) + (defun mouse-set-point (event &optional promote-to-region) "Move point to the position clicked on with the mouse. This should be bound to a mouse click event type. -If PROMOTE-TO-REGION is non-nil and event is a multiple-click, -select the corresponding element around point." +If PROMOTE-TO-REGION is non-nil and event is a multiple-click, select +the corresponding element around point, with the resulting position of +point determined by `mouse-select-region-backward'." (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 mouse-select-region-backward + (when (> (posn-point (event-start event)) (region-beginning)) + (exchange-point-and-mark))) + (when (eq mouse-select-region-backward 'keep) + (sit-for 0) + (exchange-point-and-mark))) ;; 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)))) A problem with the `keep' choice is that, when the region is too big for the window, there is a somewhat jarring flicker due to exchanging point and mark twice and redisplayin in between, and perhaps even worse, when scroll-conservatively is 0, the region shown in the window can be smaller than the text shown before selecting, due to recentering. But for smaller regions, the `keep' choice could be a useful option. Do you have a preference between these two alternatives? (Perhaps Noam and Drew wish to chime in here, since they in effect commented only on the `keep' choice, not the `move' choice.) Steve Berman