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 08:23:31 -0700 (PDT) Message-ID: <7bed1f76-5bae-44cb-9b22-206b513043be@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> 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 1536938626 14728 195.159.176.226 (14 Sep 2018 15:23:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2018 15:23:46 +0000 (UTC) Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, acm@muc.de, phillip.lord@russet.org.uk To: Eli Zaretskii , Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 14 17:23:41 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 1g0pwa-0003hd-I2 for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 17:23:40 +0200 Original-Received: from localhost ([::1]:52218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0pyh-0003Ys-7I for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 11:25:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0pwn-0002RJ-5k for emacs-devel@gnu.org; Fri, 14 Sep 2018 11:23:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0pwl-0003H2-So for emacs-devel@gnu.org; Fri, 14 Sep 2018 11:23:53 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:58802) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g0pwh-00038m-Ne; Fri, 14 Sep 2018 11:23:47 -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 w8EF4MQL139698; Fri, 14 Sep 2018 15:23:36 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=TaSLx6Fi3ZGw73l2FvjxDU0cn7hvDoMtgCbukssH3oQ=; b=Af/pMStEggkVNRCVEvVnWuTXCXyzaUYJEEbZlH2+yMwcx7T80qmZux/3qez5VeU7rrez 3AHIx44mI1rEeuWBQ9q9ZKvIKYTH11TrDqnE5eUDPKk5RvMyN7FinIR0dLYtQfrOBksU mbJIzMjfMQFw0lVUwIt25lNEmcHTj7iQ6S6SqUHEwCmgjWQMiadMSD3Mbzy8MWdqMYaH ZnVpqWDtAskbbEhC9ddacrkbnuuVtuPwtwEj4Kgvk0mPRyTUyoRMmctP8t9pjAi4Uwq8 hsWl6kH652m020S2E6FoIkR1VxBzmTZ4GzjRU5PthScee7tFlLYoJet6kzix6CdqbNwT dg== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2mc6cq7rn8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 15:23:36 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w8EFNYxi027135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 15:23:34 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w8EFNWWa000374; Fri, 14 Sep 2018 15:23:32 GMT In-Reply-To: <83k1nojgia.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=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-1809140155 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:229786 Archived-At: > 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.) >=20 > 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. `delete-selection-mode' is 5 well-defined behaviors for the active region, carried out when you invoke a command. It's nothing more than that. Which of those 5 behaviors to use depends on the command you invoke when the region is active. Users can trivially control which of the 5 behaviors to use for a given command, just by putting a property on the command symbol. These are the possible property values and associated behaviors: 1. nil: Do nothing (no-op). Same as turning off d-s-m mode for that command. 2. non-nil and not one of the symbols below (default): Delete (do not kill) the active region (`delete-active-region'). Then invoke the command. 3. `kill': Kill the active region (`kill-region'). Then invoke the command. 4. `supersede': Just delete the active region. Do not invoke the command. 5. `yank': Delete the active region, and make sure that the text deleted is not the same as the text that gets yanked. (Used only for a command that yanks.) 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. A user or code can turn d-s-m off anytime. Or turn it off for any given command (#1 above). > 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. Yes. > 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. There is no 3rd meaning of the region. There is not even a 2nd meaning. There is one meaning of the region - the text delimited by point and mark. If t-m-m is on then the region can have two states: active or inactive. If the region is active and d-s-m is on then it can be automatically deleted when you invoke a command. That's all. There is nothing complicated or mysterious about d-s-m. If there were - if there were some crazy irreconcilability, then the same would be true of `C-w' and `delete-active-region'. There is also nothing complicated or mysterious about t-m-m. There is also nothing complicated about Emacs behavior when t-m-m and d-s-m are off. 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. I do think it would help to have a command that only activates the region. Making `C-x C-x' do double duty is truly one place where confusion can get sown. It should be _able_ to do double duty, for convenience. But users should also be able to only activate the region and only swap point and mark - as separate operations.