From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: delete-selection-mode as default Date: Fri, 14 Sep 2018 07:33:01 -0700 (PDT) Message-ID: <84ef5fa1-5adc-4832-b4f4-f115b9753b40@default> References: <83k1nxvm5j.fsf@gnu.org> <87sh2ih0bp.fsf@fastmail.fm> <770f48a8-664a-40ae-8e03-19f6aad248b6@default> <20180910181615.GA4829@ACM> <874lev3bq4.fsf@toy.adminart.net> <20180912131602.GA5582@ACM> <87d0tihxzw.fsf@toy.adminart.net> <20180913174640.GB4019@ACM> <8736udkuit.fsf@toy.adminart.net> <20180914104833.GA4103@ACM> 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 1536935486 30609 195.159.176.226 (14 Sep 2018 14:31:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2018 14:31:26 +0000 (UTC) Cc: spacibba@aol.com, Joost Kremers , Noam Postavsky , emacs-devel@gnu.org, Eli Zaretskii , phillip.lord@russet.org.uk To: Alan Mackenzie , hw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 14 16:31:21 2018 Return-path: Envelope-to: ged-emacs-devel@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 1g0p7u-0007n2-6S for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 16:31:18 +0200 Original-Received: from localhost ([::1]:51990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0pA0-0004tM-PC for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 10:33:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0p9p-0004sK-BH for emacs-devel@gnu.org; Fri, 14 Sep 2018 10:33:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0p9o-0003tj-EQ for emacs-devel@gnu.org; Fri, 14 Sep 2018 10:33:17 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:51596) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g0p9k-0003o1-Gg; Fri, 14 Sep 2018 10:33:12 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8EET1ja078988; Fri, 14 Sep 2018 14:33:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=xOKLUbllyf/QZFjwQGAJsJrtuysmfV5NbxAL76kYAJo=; b=ZafgYQwk9jd+/qoWSVmyZKulLpKHnX7JBnj8ISbmk6dKkUsuWcCVJ76KhfUwWbdFP2kV RoLdWKF7NEWTgE4OUYGpCgVxuIQ0+FB6vqoh9mqad1Gfr1ITT+jnbff22JV8BuAKs+Oa TlCKTekQfdJ3w9gHUGnPneCn3Ku1xGP4PLuvLHmcDpk05cT823Qrw5Q5A2eibg4dRUTk Xea1QBekH9TG2TuWC8MsNzmCo4AjayF5Khp3Swx1xcOF5BMc/HtIrIwbk4npJqS9u9TM 0dyUYnH9Wa6/u58HBAey+GmodKyBt0fdHhGWvQ/fYmA3GOVYnUQsI0k36qgGHH2/hobd zA== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2mc5utyfn7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 14:33:03 +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 w8EEX2A7009051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 14:33:03 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8EEX2CQ016487; Fri, 14 Sep 2018 14:33:02 GMT In-Reply-To: <20180914104833.GA4103@ACM> 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=9015 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809140150 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.86 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229781 Archived-At: > This may be your main problem. The concept of "selection" doesn't really > exist in Emacs as such. So your desire for there either positively to be > a selection or not be a selection at any given time doesn't really make > sense. In Emacs there is point and (usually) mark, which delimit the > region. If you want to regard the region as being "the selection", you > can, but if you try to extend that to "there always being a selection", > you run into conceptual trouble. That's what I think has been happening, > here. Actually, Emacs recognizes and has support for selections: the primary and secondary selections, if they exist. See (emacs) `Primary Selection'. But your main point is valid. The Emacs region can make use of or change the primary selection, but the two are not the same thing. And users can configure how much they want the region to interact with the primary selection. It is in part because of the existence of both the region (point and mark) and the primary selection that things can get complicated and users can choose quite different behaviors from each other. This is all Emacs - there is no one Emacs way when it comes to these things. But it is true that, however a user might choose to manifest it or have it behave, there is always the Emacs region (point and mark), as soon as a buffer has a mark. Keeping in mind the possible behaviors that other users might choose can be tricky, partly because we tend to know so well how "our" Emacs behaves and not so well how "their" Emacs behaves. When it comes to discussing what the default behavior should be, a prerequisite is that we try to learn about and keep in mind the "other" behaviors. Easier said than done, no doubt. Hw (and others): The behavior that Alan is describing - the one he chooses for Emacs, is the original Emacs region behavior. It is not some crazy, odd, or dangerous thing. It's a perfectly fine, efficient, and logical behavior. And yes, it is specific to Emacs - not known much, if at all, outside Emacs. It is no longer the default behavior, but it was for a long time. The current default behavior of Emacs wrt the region is what it is. In a way, I'd characterize it as being between two chairs, but it is not so bad or uncomfortable. I'd prefer that we turn on `delete-selection-mode' by default, but it's apparently already been decided (by RMS and Eli) that that won't happen just yet. Not a big deal. ---- We might want to consider making more obvious some of the main user choices regarding region, selection etc. I think it's not obvious to users, especially new users, what choices are available. I don't have a concrete suggestion of how we might do that, but I think there's probably room for improvement. The various variables, modes, etc. that control the behavior are here and there, and their presentation in the docs is also here and there. Depending on the choices you want, the notion and behavior of the region can have to do with cutting and pasting, navigation, acting on a stretch of text, narrowing, highlighting, mouse selection, and other things. You'll find some info in the docs under `Cut and Paste', some under other topics. And that's normal. The region affects almost everything, and it can behave differently for different uses and different people. But maybe there could also be some place where the modes and options that govern region-related behavior are discussed together. Dunno. I don't mean repeating what's said elsewhere in the doc, but somehow bringing these things together. A Customize group might be a start, though that wouldn't really provide an organized presentation of the main choices/approaches. Just wondering out loud, I guess. I don't have anything really to offer about this. I see a problem/opportunity more than a concrete solution in this regard. Whoever (Stefan?) suggested providing various high-level user "profiles" or whatever - behaviors to try on, had a good idea. For region-related behavior that could perhaps be as simple as defining some modes or options that combine existing modes and option values. If that were done then its presentation in the doc would maybe correspond to what I suggested (above) is missing.