From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#23478: 25.0.93; Mouse region selection asymmetry Date: Mon, 4 Jul 2016 15:29:54 +0000 (UTC) Message-ID: <3c435aac-aab0-46b6-97a7-4a90badfafea@default> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1467646442 14455 80.91.229.3 (4 Jul 2016 15:34:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2016 15:34:02 +0000 (UTC) Cc: 23478@debbugs.gnu.org, npostavs@users.sourceforge.net To: Stephen Berman , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 04 17:33:47 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 1bK5sW-0005z6-P5 for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jul 2016 17:33:45 +0200 Original-Received: from localhost ([::1]:48624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK5sV-0005un-W3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jul 2016 11:33:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK5py-0002fi-Ib for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 11:31:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bK5pu-0006sc-GY for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 11:31:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK5pu-0006sY-Cc for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 11:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bK5pu-0001An-4f for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 11:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jul 2016 15:31:02 +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.14676462074446 (code B ref 23478); Mon, 04 Jul 2016 15:31:02 +0000 Original-Received: (at 23478) by debbugs.gnu.org; 4 Jul 2016 15:30:07 +0000 Original-Received: from localhost ([127.0.0.1]:37249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bK5p1-00019e-He for submit@debbugs.gnu.org; Mon, 04 Jul 2016 11:30:07 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bK5oz-00017t-KC for 23478@debbugs.gnu.org; Mon, 04 Jul 2016 11:30:06 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u64FTwm2018542 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Jul 2016 15:29:58 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u64FTvIj030535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Jul 2016 15:29:57 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u64FTtUO027636; Mon, 4 Jul 2016 15:29:56 GMT In-Reply-To: <87wpl17pvs.fsf@gmx.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] 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:120401 Archived-At: > If by "it" you mean the new behavior, then I agree nobody needs it, in > the sense that it doesn't provide any functionality you can't get > another way (e.g. by selecting a region by means of key combinations by > dragging the mouse instead of by double-clicking). Nevertheless, I've > always been slightly annoyed when I've encountered the issue, just never > enough to try and do anything about it till now. >=20 > >> I think opting in is best in cases where it's > >> likely that some people may prefer (or some code may depend on) the > >> existing behavior, or where the new behavior may bring a disadvantage = in > >> some case. But I don't think any of that is likely in this case > >> (indeed, I really think the existing behavior is a misfeature). Your > >> concern about the interaction with scroll-conservatively applied to my > >> initial patch, but you yourself suggested a better alternative that > >> allays this concern. Given that, I ask again, and not rhetorically, d= o > >> you see a strong downside to having the new behavior be the default? > > > > 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. >=20 > 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: >=20 > 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. >=20 > With the patch the behavior is now simply this: >=20 > 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). >=20 > 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. I haven't really been following this thread. Now that I've read the summary description of the problem (I have not tried the fix), here are my two cents, FWIW. 1. I agree with Eli about new features generally being opt-in, not opt-out. Actually, he spoke of "backward-incompatible behavior", and I agree with that "almost always" approach too: "I think backward-incompatible behavior should almost always be opt-in, unless we have no choice." 2. I see plenty of _bug fixes_ that have backward-incompatible behavior, and that are neither opt-in nor "have no choice". No, I'm not going to look for a list of them. But this is definitely my recollection and impression. (And it is usually not a problem - I am not complaining that it is here.) 3. In this particular case, I agree with Stephen. I really don't see why someone would complain about this fix. And if someone does then it should be easy enough to discuss and DTRT at that point. 4. Also in this case, as Eli said, this is not a big deal either way. But I see (so far) no reason for keeping both behaviors and providing a user choice here. If the non-recentering behavior were the case for both directions then I can imagine that someone might argue for a choice (recenter or not). But I don't think that will happen here. In sum, FWIW my vote would be to fix this unconditionally, and not bother with a user option for this. (This should apply only to the case where the entire region _can_ be shown in the window, of course. If it cannot (too big), then there is little reason to recenter.)