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 13:57:59 -0700 (PDT) Message-ID: <1c393214-c186-4760-9a37-e0450c946446@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>> <> <<83k1nojgia.fsf@gnu.org>> <<7bed1f76-5bae-44cb-9b22-206b513043be@default>> <<83d0tfkj77.fsf@gnu.org>> 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 1536958576 26576 195.159.176.226 (14 Sep 2018 20:56:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2018 20:56:16 +0000 (UTC) Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, phillip.lord@russet.org.uk To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 14 22:56:10 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 1g0v8L-0006la-Ua for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 22:56:10 +0200 Original-Received: from localhost ([::1]:53312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0vAS-0004y6-Jz for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 16:58:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0vAL-0004y0-Hy for emacs-devel@gnu.org; Fri, 14 Sep 2018 16:58:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0vAK-0002Lr-BX for emacs-devel@gnu.org; Fri, 14 Sep 2018 16:58:13 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:37336) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g0vAG-0002Ij-Oi; Fri, 14 Sep 2018 16:58:08 -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 w8EKss2A118387; Fri, 14 Sep 2018 20:58:01 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=GzYBUMHByrK7CWt8WQ8M91H1w1k9qXWz9Rmyfmlw0g0=; b=V1jaVNi3yKI2piPXi4Y3p10L1wbMDWhr/6EwLIN3PiqgEXUzLxORvZ/dfxYucfORahyA 4QBZLRkUjIWBiKju+mMr6lPWw44vQiahx0gDJ3ggN9GOLVP0b/exzM45PH5LFCI7WMR+ DTXEJa4zoAvBr4o2CoVd2ISwFWRj8na1wuOnQOVXrnD/bn2p8qux126T+D52A7RxiFl/ 2VkyM9+Mr1zD1flQbtpX4QsIFghtHrAP5bU05MOsE97z0LqKXhdLRueXb7Dhwa2XkZUB w2eN4IjZRNdHRew1E6ahiAMVbby7YPqQB5xy4ZN6OL9aTwyXdS4TvYHNDUqhBNMI5k32 yA== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2mc6cq95hp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 20:58:00 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w8EKw0lT023057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 20:58:00 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w8EKvxDE003989; Fri, 14 Sep 2018 20:58:00 GMT In-Reply-To: <<83d0tfkj77.fsf@gnu.org>> 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=9016 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-1809140211 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.78 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:229794 Archived-At: > > Users can trivially control which of the 5 behaviors to use for > > a given command, just by putting a property on the command > > symbol. >=20 > Putting properties on symbols to change the behavior of a command is > not user-level customization. IOW, we are miscommunicating. There are users, and there are users. I didn't say that users will do that in general. Far from it. I don't know anyone who has ever bothered to set the d-s-m behavior for a particular command, unless it's a new command that they themselves created. That's the typical use case: causing your own command that's similar to standard `yank' or `backward-delete-char-untabify' or... to behave like the standard command wrt d-s-m. If you create a yank command then you want d-s-m to treat it as such (not to yank back the text that it just deleted). Typically this is done for a library, but it could be done in a user init file. The point is that you can, if you need/want to, _trivially_ define the specific behavior for a given command. Nothing complicated for any user to do that, even if very few will ever need to. > > There's no difficulty "reconciling" d-s-m with the "other > > uses" of the region that you cite. None whatsoever. > > You've shown none, AFAICT. No trick is needed. It just > > works. >=20 > This whole thread makes it acutely clear that there is a problem. I disagree that there is a problem with d-s-m, or with turning it on by default. You tout irreconcilability but give no example. It's true that problems have been cited in the thread: Misunderstandings come from mistaken expectations and the fact that different users use Emacs differently. Confusion can come from the fact that there are multiple knobs to control region behavior (and not just two modes, t-m-m and d-s-m), and it's not obvious sometimes that a given knob exists or how the various knobs interact. That users can be confused about the region etc. does not stem from d-s-m - please don't scapegoat it. Confusion comes primarily from the introduction of t-m-m and, especially, the coupling, in C-x C-x, of region activation with swapping point and mark. There was no confusion before that. And no confusion was introduced by adding d-s-m. The fact that users who might want to really understand all of the various possibilities need to scour the manual to find info that is spread all over the place is too bad. I mentioned some possibilities for helping with that. But normally a given user just knows what s?he uses, and doesn't try to know about and understand every possibility regarding point, mark, region, selection, activation, highlighting, action, deletion, etc. This discussion, since it now deals with all possibilities (because people who take different approaches have widened the scope), has made apparent the complications. But a given user normally doesn't sense how complicated this stuff can be. Mr X knows his way of using the region; Ms Y knows her way, and so on. > And your message actually agrees with me towards the end. Again, I disagree. Do you mean the text cited just above? If not, where do you think I've agreed with you that there's inherent difficulty "reconciling" d-s-m with the "other uses" of the region that you cite? You make it sound like things are crystal clear and simple with the status quo, and that defaulting to d-s-m would muddy the waters. In fact, the waters are muddy now, if one bothers to look into them. And those umpteen knobs I mentioned do not come from d-s-m. You've correctly pointed out that the discussion, e.g., between Alan and Hw, ranging to `mark-even-if-inactive' and beyond, has pointed out complications. What's not correct is to suggest that the complications come from d-s-m. It's wrong to suggest that all is harmonious between your first two region "uses": navigation and invoking commands on a region, and that your third "use", delete-selection-mode, is the irreconcilable culprit that threatens to spit in the soup and turn harmony into discord. Defaulting to d-s-m would just make life simpler for most users (IMHO). And those who don't want d-s-m on can turn it off. And whether it is on or off, or whether d-s-m even exists or not, the complications we've pointed out are present - they don't come from d-s-m mode. You've decided that d-s-m won't be on by default anytime soon. OK. But it's wrong to paint a picture of d-s-m as a bogey man that threatens to sow contradiction.