From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Mark set by ?mark-*? not deactivated by point motion Date: Mon, 17 Sep 2018 12:39:55 -0700 (PDT) Message-ID: <7746d008-7a6f-456f-926e-28a0ec13cd7e@default> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1537213115 1316 195.159.176.226 (17 Sep 2018 19:38:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Sep 2018 19:38:35 +0000 (UTC) To: Stefan Monnier , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Sep 17 21:38:31 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g1zLq-00008k-LA for geh-help-gnu-emacs@m.gmane.org; Mon, 17 Sep 2018 21:38:30 +0200 Original-Received: from localhost ([::1]:37148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1zNs-00067D-2E for geh-help-gnu-emacs@m.gmane.org; Mon, 17 Sep 2018 15:40:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1zNQ-00064T-Iw for help-gnu-emacs@gnu.org; Mon, 17 Sep 2018 15:40:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g1zNN-0000bt-9f for help-gnu-emacs@gnu.org; Mon, 17 Sep 2018 15:40:08 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:46858) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g1zNM-0000S3-T0 for help-gnu-emacs@gnu.org; Mon, 17 Sep 2018 15:40:05 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8HJYHEU018616; Mon, 17 Sep 2018 19:39:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=OfdYJL3js84JpIo0QG3rIKBXrztO6V2lu0OZXnD6820=; b=k6sTlrfYvrhWIBJHywiVghZ6SV9Ml9yfeQmyGWxLrk5siJ4AWhsnhGnughDsdzDv5BWD yAWCTS1jVn7Io8B8nKMLzoiIzocLnQ9+4LXmAH5y/rWcuaRqo5S3Fy5WPnXFI+AjhrBV WvLQC2gl9ThnisE/eGdL8mhM5PR5iX5qNgdXKZft8Lq0LEiOoO4W5jmXkMxLJC0nZyFG zo5XyFiZ6HvVGYz4YEegPW3/oCQlviBcMaKniR3mTOtEhdI8Lz0HKQr8v+lh4ERKydiQ cYko5hvRtttnz2uX6evIIZW4+ofbBsLi5LHV6lefoaPhMK1nsVKtt1cLTeOTgkSOG+/H DA== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2mgt1pgdm9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Sep 2018 19:39:57 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w8HJduTA007827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Sep 2018 19:39:56 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8HJdtDw024413; Mon, 17 Sep 2018 19:39:56 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4735.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9019 signatures=668708 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=574 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809170194 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.78 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:117946 Archived-At: > I'm more wondering about why you'd mark a word with M-@ only to > immediately afterwards deactivate the region. >=20 > I never use M-@ but I use C-M-SPC all the time, and very often I do > C-M-SPC (maybe repeated a few times) followed by some cursor motion > (including C-x C-x sometimes) to "fine tune" the boundaries of the > active region. >=20 > So I rely on this behavior very frequently and I find it rather > convenient not to have to re-activate the mark explicitly when I'm done > tuning its boundaries. >=20 > On the contrary, I find the deactivate-mark behavior of > "navigation after shifted-navigation" to be a mis-feature: it forces me > to be careful to keep the shift key pressed until I'm really done > setting up the region and it prevents me from using navigation commands > which I can't use in a shifted form (or which don't (yet) support > shift-select-mode). I don't mind very much, tho: I just use C-SPC > instead, but I think in terms of UI, navigation should never deactivate > the mark. >=20 > I have the impression that this behavior was simply copied from other > applications, and those don't have something equivalent to Emacs's C-g, > so their users are used to making a dummy un-shifted cursor movement > when they just want to deactivate the selection. But in Emacs we have > C-g for that. I can see both points of view. The behavior objected to here by Yuri is fairly standard in Emacs, but Emacs does not follow it everywhere. A case where the behavior follows instead what Yuri expects for this is selecting text with the mouse (in any way: double-click, mouse-1 then mouse-3 etc.). In this case immediately subsequent cursor motion does deactivate the region. Whether Emacs should be consistent in this regard, I don't know. But apparently Emacs presumes that if you use `M-@' to select a word (put the active region around it) then you intend cursor motion to extend it. And apparently it presumes that if you double-click mouse-1 to select it then you do not intend cursor motion to extend it. A guess is that the latter choice is because it presumes that you will use only the mouse to extend it. That's not bad reasoning, I think, but it does make for some inconsistency, so maybe it can confuse some users. I tend to like the existing behavior, FWIW. But especially in cases where there is no mouse equivalent I think it's helpful to be able to use keyboard and mouse together indifferently. In that context, see bug #32747.