From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: delete-selection-mode as default Date: Sun, 16 Sep 2018 00:37:43 +0200 Organization: my virtual residence Message-ID: <874leq799e.fsf@toy.adminart.net> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1537051063 29009 195.159.176.226 (15 Sep 2018 22:37:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2018 22:37:43 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, Yuri Khan , acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 16 00:37:38 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 1g1JC2-0007M9-NU for ged-emacs-devel@m.gmane.org; Sun, 16 Sep 2018 00:37:34 +0200 Original-Received: from localhost ([::1]:56966 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1JE9-0003nx-7O for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2018 18:39:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1JD0-0003mD-4j for emacs-devel@gnu.org; Sat, 15 Sep 2018 18:38:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g1JCx-0002dT-Do for emacs-devel@gnu.org; Sat, 15 Sep 2018 18:38:34 -0400 Original-Received: from mo6-p02-ob.smtp.rzone.de ([2a01:238:20a:202:5302::10]:32569) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g1JCx-0002Z9-6u; Sat, 15 Sep 2018 18:38:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537051109; s=strato-dkim-0002; d=adminart.net; h=References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=TvcF45GViZzPPlfn77ZAIIYkaQAj92L6Wg66y+BtxfA=; b=F42vJYvvcUjdXUOJ77SAwY/WuUDLAGufsmR/P2/kETM7aPKPwn4E3Hq0hd+vc4IArL p/jCPRK7dPY6DvHrpRnSX2jRIFmE0XdTKyXYBApLF2ez/MVymTZvTcBKO9WcamSONB9m MJ//9PsSAvYor9vvs0xL+dzVTQo3GzrJTa5oRxh6gLIHcN/ywNduGySmmG90Prny1w++ Za+NJjDjbCtLcLY/WRml1ux2+WSrT2bjBDBRljM6+TR3AHafspqYQE9tj6Ueos8Lkb3W yZ10sZ8wjVzvmMf2OGQ/LpVAyDTM7zgcjxJu38mshFvEKZDWSE/BYi8kusuydewe4u9p RzJw== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 44.1 DYNA|AUTH) with ESMTPSA id 20bdb7u8FMcN6D5 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 16 Sep 2018 00:38:23 +0200 (CEST) Original-Received: from toy.adminart.net ([192.168.3.55]) by himinbjorg.adminart.net with esmtp (Exim 4.90_1) (envelope-from ) id 1g1JCp-0001Lk-17; Sun, 16 Sep 2018 00:38:23 +0200 In-Reply-To: <83k1nojgia.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Sep 2018 17:33:17 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5302::10 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:229828 Archived-At: Eli Zaretskii writes: > [...] > The region is currently used for 3 purposes: navigation, invoking > commands on a region of text, and delete-selection-mode. You don't need a region for commands to work on, a selection is enough. That would allow to decouple navigation from (making) selections, and the concept of a region becomes obsolete, removing all the entanglement and greatly simplifying things. > (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.) That's why I said it's misguided in that it is an entirely different idea. > 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.) Just use a selection for commands to work on? There's no need to particularly activate a selected part of a buffer; it's kinda what a selection is for. A region is not needed here, either. > The third use of the region, the one needed for delete-selection-mode, > is IMO impossible to reconcile with the other two. I'll leave that aside because it's an entirely different idea which may be served with its own independent implementation. For such an implementation, a region is not needed. Perhaps it could be implemented as an optional feature of selections. > Instead of trying to reconcile them with some trick, we should > consider introducing a new "state" of the region, You mean like a selection? :) Those do not require regions. > which will be activated by a special command, Since a region is obsolete, we could simply use C-spc to start making a selection and another C-spc to finish it. > or could be optionally activated by "C-x C-x" etc., given some > optional setting. That is for navigation. A region is not needed for navigation between two points. You only need the two points, in this case, called mark and point. Just decouple them from selections. Once decoupled, there could be a command to turn the "region" that can be imagined between mark and point into a selection. There is no need for a region here, either. > 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. Users preferring d-s-m could enable the deletion option of selections. Then if they want to delete a selection, they can make one and overwrite it. This doesn't need to be complicated. >> With transient-mark-mode being the Emacs default, I=E2=80=99m 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. What when they implicitly and secretly activate something you wanted deactivated and do something you didn't expect? When a selection is required for a command that does something with a selection, the command can not work when there is no selection, and it is a bug when it does so nonetheless, like through Emacs assuming there was a selection when there actually is none (because Emacs lacks the ability to distinguish if something is selected or not because its insistence on obsolete regions gets in the way). It's a clash between transient-mark-mode enabled and disabled. In one case, the behaviour is a bug because the mode suggests that commands doing something must not do it with regions but with selections (active regions); in the other, it's fine because there is always something for commands that do something with something to do what they do because there's always a region, and the second case implies that it is generally fine for software to make mistakes of the users worse rather than protecting them from them. Actually, the second case is merely a slip-up, like driving your car into the wall at full throttle and no seat belts on, either just because you can, or unintentionally. For some reason, only with transient-mark-mode enabled, this becomes obvious because it has been overlooked at least for the unintentional variant. It probably was never wanted even without transient-mark-mode, i. e. the intentional variant. Or why would I want something like upcase-region to suddenly mess up random parts of a buffer? A region is not a selection, it's only a random part of the buffer that has somehow gotten between mark and point, perhaps when mark and point were used for navigation, or when I moved around, or when the mark happened to be set somewhere last time I yanked something, or when the cat stepped over the keyboard while I was pressing Ctrl or when it hit the cursor keys ... > 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 indication is whether there is a selection or not. Isn't that the idea behind transient-mark-mode, an idea that made this mode so successful that it became the default? When you do not want to limit a command to a region, you do not need a region, and the region is not needed here. When you want to limit or to extend a command, you can use a selection to limit or extend it to, and you don't need a region, either. > 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. The problem is the region. It's not needed for anything and keeps getting in the way.