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#18590: 24.3.93; Scrolling changes/forgets selection Date: Tue, 30 Sep 2014 09:43:05 -0700 (PDT) Message-ID: <4a1fd296-dc2f-4fb3-a854-0b4acea62f72@default> References: <<69d7a976-96b7-49c6-bb96-e69f2fa8c93e@default>> <<83fvf9ktwd.fsf@gnu.org>> 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 1412095473 6763 80.91.229.3 (30 Sep 2014 16:44:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 16:44:33 +0000 (UTC) Cc: 18590@debbugs.gnu.org, nljlistbox2@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 30 18:44:26 2014 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 1XZ0XI-0008I1-Rg for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Sep 2014 18:44:25 +0200 Original-Received: from localhost ([::1]:44400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZ0XI-00013X-HM for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Sep 2014 12:44:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZ0X8-00012g-3G for bug-gnu-emacs@gnu.org; Tue, 30 Sep 2014 12:44:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZ0Wx-0005aV-EQ for bug-gnu-emacs@gnu.org; Tue, 30 Sep 2014 12:44:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZ0Wx-0005aR-Ap for bug-gnu-emacs@gnu.org; Tue, 30 Sep 2014 12:44:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XZ0Ww-00085W-Rl for bug-gnu-emacs@gnu.org; Tue, 30 Sep 2014 12:44:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Sep 2014 16:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18590 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18590-submit@debbugs.gnu.org id=B18590.141209539630999 (code B ref 18590); Tue, 30 Sep 2014 16:44:02 +0000 Original-Received: (at 18590) by debbugs.gnu.org; 30 Sep 2014 16:43:16 +0000 Original-Received: from localhost ([127.0.0.1]:56519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XZ0WB-00083u-SE for submit@debbugs.gnu.org; Tue, 30 Sep 2014 12:43:16 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:22008) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XZ0W7-00083g-6D for 18590@debbugs.gnu.org; Tue, 30 Sep 2014 12:43:12 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8UGh8oH025174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Sep 2014 16:43:09 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8UGh6SK025331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Sep 2014 16:43:07 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8UGh6K3010800; Tue, 30 Sep 2014 16:43:06 GMT In-Reply-To: <<83fvf9ktwd.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:93925 Archived-At: > > The same thing does not happen if you select with the mouse (e.g. > > drag the selection past the window bottom. >=20 > Of course it does: dragging the mouse moves point. What I said is that loss of the starting position, as one end of the region, does not occur. You can use `C-x C-x' to select the region between the new point (where the mouse dragged to) and the starting position of the drag. The fact that the window scrolled during the drag does not affect this region. Which is as it should be. > > And it does not happen if you set mark and then use C-v to move > > past the window bottom. >=20 > Only point must be in the view; the mark might be outside of it, as > you well know. Yes. And both mouse dragging and C-SPC set the mark (which they should). > > And if I select a bit of text and then use the mouse wheel to > > scroll the window I don't see the problem either. >=20 > You don't use Emacs, if you don't see the problem. C-SPC C-5 C-f Then scroll using the mouse wheel. Then C-x C-x. The region is from point back to the mark. As it should be. Or press mouse-1, drag it a few chars, and release mouse-1. Then scroll using the mouse wheel. Again, C-x C-x selects from the new point back to the mouse-drag starting position - because mouse drag sets mark. Again, the behavior is as it should be. Or S-right a few times, to select a few chars. Then scroll using the mouse wheel. Again, C-x C-x selects from the new point back to where you first used S-right (the mark). Again, the behavior is as it should be. All of these are what I meant by not seeing the problem with mouse-wheel window scrolling. What did you mean by it? All of these behaviors are similar. I thought, but I guess now that I was mistaken, that I saw the following, different behavior for the scroll bar: Select some text (using any method) and then scroll using the vertical scroll bar. I thought I saw that the region was kept active (and point was of course moved to follow the window scrolling, as it should be), but the other end of the active region changed from its original beginning to the new window start position. So C-x C-x lost the original region start and was now between the new point (from scrolling) and the window-start position. I could have sworn that I observed that (including this morning), but I cannot seem to repro it now. So I guess scroll-bar scrolling is not problematic either. Sorry for that noise. --- Actually, now that I think more about it, I think the seeming gotcha is this, and it corresponds to the OP report wrt C-x h. Because scrolling moves point, if the direction of scrolling is toward the mark (away from point) then the original position is lost, and you cannot recuperate it. This is logical, but it can seem unnatural. E.g.: Double-click the opening or closing paren of a defun. That puts point at the end of the selected defun. C-x C-x to put point at the beginning (for whatever reason). Now scroll down. Scrolling moves point, of course. Visually, you can (mistakenly) think that the region is being extended _from the original point_, past the mark, to the scroll position (new point). Of course this is not the case - the region is always between the mark and (the new) point. It can seem unnatural because (a) the defun was selected initially, (b) scrolling visibly extends the region, and (c) the other (mark) end of the region is no longer on the screen, so you do not see that the region no longer includes the initially selected defun. I don't know whether it might make sense for scrolling to first either deactivate the region or swap point and mark (if it keeps the region active). If it deactivated the region the same "problem" would be present, but at least you would not see the region being extended and mistakenly assume that it was being extended from the farthest position from the scroll direction (i.e. from point). Am I being clear? Maybe put it this way: With some text selected (and the region active), regardless of which end of the region point is, the region would be kept active (as now), but point would first be swapped with mark, whenever the scrolling direction was toward mark (away from point). What this would amount to is trying to compensate for possibly forgetting to use C-x C-x to swap point and mark _before_ scrolling.