From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: delete-selection-mode as default Date: Fri, 14 Sep 2018 17:33:17 +0300 Message-ID: <83k1nojgia.fsf@gnu.org> 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=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1536935681 13262 195.159.176.226 (14 Sep 2018 14:34:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2018 14:34:41 +0000 (UTC) Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 14 16:34:36 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 1g0pB5-0003JW-Vv for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 16:34:36 +0200 Original-Received: from localhost ([::1]:52007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0pDC-0006eb-Jt for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 10:36:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0pBb-0005w3-62 for emacs-devel@gnu.org; Fri, 14 Sep 2018 10:35:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0pBV-0007H9-H7 for emacs-devel@gnu.org; Fri, 14 Sep 2018 10:35:06 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0pAM-00059h-E6; Fri, 14 Sep 2018 10:33:50 -0400 Original-Received: from [176.228.60.248] (port=2286 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g0pAJ-0000Lb-Vp; Fri, 14 Sep 2018 10:33:50 -0400 In-reply-to: (message from Yuri Khan on Fri, 14 Sep 2018 20:41:46 +0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:229783 Archived-At: > From: Yuri Khan > Date: Fri, 14 Sep 2018 20:41:46 +0700 > Cc: hw@adminart.net, spacibba@aol.com, > Joost Kremers , Noam Postavsky , > Emacs developers , Eli Zaretskii , Drew Adams , > Phillip Lord > > *The* core concept of Emacs as I understand it is its infinite > customizability, and this is pretty much the main reason I stick with > it. There are limits to customizing Emacs. Beyond those limits, what you have is the basic ideas on which Emacs is based; if you want to change them, you will have to write a different editor. The region is one such basic idea. If you want it to behave exactly as selections in other editors, you are not talking about Emacs. We can (and do) provide approximations to what other editors do with selections, but they are just that: approximations. So I suggest not to ignore what Alan says, because I think there's a hard nut of truth there, which we should endorse if we want to have a common language. IMO, the basic conundrum of what we have now with transient-mark-mode and delete-selection-mode is that we are trying to cover turf that cannot be covered by a single feature. As result, large groups of users will become unhappy, no matter what we do. The region is currently used for 3 purposes: navigation, invoking commands on a region of text, and delete-selection-mode. (If someone thinks that delete-selection-mode is a variant of "invoking commands on a region of text", they are mistaken, and this long discussion is one proof of that mistake.) It should be clear from this discussion that there are fundamental tensions between these 3 purposes. The first two can be reconciled by using the "active" vs "inactive" region, something we already have. This distinction is needed because an Emacs buffer will almost always have a region, and therefore users need some knob to control whether a command should act on the region or on the entire buffer. (It is possible that we need some new command to "activate" the region, because the current method are IMO unsatisfactory: they require navigation, which is totally gratuitous.) The third use of the region, the one needed for delete-selection-mode, is IMO impossible to reconcile with the other two. Instead of trying to reconcile them with some trick, we should consider introducing a new "state" of the region, which will be activated by a special command, or could be optionally activated by "C-x C-x" etc., given some optional setting. IOW, let the users "arm" the region for delete-selection type of commands, similarly to how they currently "activate" it for the other purpose. Then the user could decide what exactly they want the region to provide, and the basic conundrum is gone. > With transient-mark-mode being the Emacs default, I’m inclined to > consider it a bug that certain commands act on the inactive region > when t-m-m is enabled, and possibly a flaw that (interactive "r") > makes it so easy to define such commands. It's not a bug, it's a feature: commands that make no sense without the region, like "upcase-region", should not need me to activate the region for them to do what I expect them. Other commands, which make sense both when there is and there isn't a region, need an indication of what the user wants them to do, and whether the region is active is that indication. The problem is that we now want to introduce yet another, 3rd meaning of the region, which is not identical to either of the other two.