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: Mon, 17 Sep 2018 23:00:06 +0200 Organization: my virtual residence Message-ID: <87va74168p.fsf@toy.adminart.net> References: <20180913174640.GB4019@ACM> <8736udkuit.fsf@toy.adminart.net> <20180914104833.GA4103@ACM> <83k1nojgia.fsf@gnu.org> <874leq799e.fsf@toy.adminart.net> <205df9be-2e5c-4cc4-a13a-7c80eb63bedc@default> <87in363zgq.fsf@toy.adminart.net> <87a7oh4mdm.fsf@toy.adminart.net> <20180916141457.GB4579@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537222468 24853 195.159.176.226 (17 Sep 2018 22:14:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Sep 2018 22:14:28 +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 , Eli Zaretskii , Drew Adams , phillip.lord@russet.org.uk To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 18 00:14:23 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 1g21mh-0006Li-4c for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2018 00:14:23 +0200 Original-Received: from localhost ([::1]:37565 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g21om-0001WP-Bk for ged-emacs-devel@m.gmane.org; Mon, 17 Sep 2018 18:16:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g21ll-0008Ea-8u for emacs-devel@gnu.org; Mon, 17 Sep 2018 18:13:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g21lk-0003U8-Bk for emacs-devel@gnu.org; Mon, 17 Sep 2018 18:13:25 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::3]:12450) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g21lj-0003Ry-03; Mon, 17 Sep 2018 18:13:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537222401; 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=hNAqwuhb1GfLhonME2+JFNn6e/xl8A+FP9j6zD2BUbk=; b=dPEsRvyE+N4HSvCU6iHQnYrVCtzKe4eOOl1ZPWTrIIIfOczKxcPiB5DvSqkD7bpc2R NvJT9wjyBnmR38+u6rUsLEYlP+lYWI8xck9xy/0oYAIH6UYXNGndXWPoQ+Dp/BoHokSD SGWd3ibEpbdhey1r7qNIucIPrbwW1dBdoTinVUA58aXLhGmuX9QSynHt6pzLqX3WjXdJ zUrRLPpjAVl8h2bhHPhdSukEeFttWyfJDsAdfazuTGVPaVwrzBApo/3KHxe0GhqB4xDB xN5z8+hlo21rv+Otyzhqn2Hu4g1JW28QTlUWgifpcH2TtnDGDsCLsvJ5iZ4spNH/bxHF gKbw== 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 20bdb7u8HMD5Axm (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); Tue, 18 Sep 2018 00:13:05 +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 1g21lQ-0000XE-Fw; Tue, 18 Sep 2018 00:13:04 +0200 In-Reply-To: <20180916141457.GB4579@ACM> (Alan Mackenzie's message of "Sun, 16 Sep 2018 14:14:57 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::3 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:229908 Archived-At: Alan Mackenzie writes: > Hello, hw. > > On Sun, Sep 16, 2018 at 15:48:10 +0200, hw wrote: > >> Oh, I see what you mean! > >> Emacs has point and (the end of) the region (selection) always entangled >> with no way to separate them or to disable the region. > > You want to disable a portion of your buffer? That doesn't make any > sense. Portions of a buffer I don't want to do anything with do not need to be selected, active or part of a region. A region is not a portion of a buffer, it's a concept. The contents of a region reside within a buffer. Disabling the region would disable the concept, not its contents. Take a picture of a tree and delete the picture. Does that delete the tree? Should I take pictures of trees I don't care about only to do nothing with them? >> That is what I dislike so much, and it causes all kinds of issues. > > I do wish you could come to understand what the region is. It would save > all sorts of problems for you. The region is not active, When you have transient-mark-mode enabled, the region can be "active". The problem with transient-mark-mode is that even when the region should be disabled because nothing is selected and nothing is highlighted, it remains enabled unless you set mark to nil. > never being any sort of agent, A region can be evaluated. In that way, it as always an agent. If you mean that it doesn't tend to do anything all by itself, well, it doesn't do that, yet if the region didn't exist, it wouldn't be possible for it to do anything in the first place, and it couldn't be evaluated. However, I could argue that the region does something all by itself when transient-mark-mode is enabled, the region is not active and an operation like downcase-region happens because the region kinda activates itself for this unless mark-even-if-inactive is nil. So yes, it certainly has a life of its own, always. > and its existence is determined only by commands which operate on it. It doesn't matter which commands operate on it. It even exists when no commands operate on it, i. e. when it doesn't need to exist. > Point exists and mark exists. When you run a command > with "-region" in its name, it operates on the buffer between point and > mark. When you're not running such a command, the region has no > significance. That's all. The region has always significance while it exists. It can always be operated on. It is a fundamental concept of Emacs. This is important because I don't want to (accidentally) do something with a region only because it always exists. That's why I make a selection. I have transient-mark-mode enabled because I want my selection highlighted. That what I'm doing becomes limited to the region is merely a side-effect, no more. It is somewhat ironic that transient-mark-mode is required to be able to fortify the region against accidental use with mark-even-if-inactive. > You are attributing problems to the region which really aren't there. A > section of your buffer is not "always entangled with no way to separate > [it]". If you don't want to do anything to the region, don't do it. And > if you do something to it by mistake, which won't happen often, use undo. I didn't say that a section of the buffer is entangled. Point and mark are entangled with making selections, with regions and with navigation. >> The secondary selection doesn't have all these problems, so it's a good >> example. > >> Can we have a mode or something in which there is no association between >> point and the end of the region? Or can I just configure that >> association away? > > Please learn what the region is. It is just a portion of your buffer. > You cannot have point dissociated from some part of your buffer. That > doesn't make any sense. Please try out joe. You can see how these things work much easier there.