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: Sat, 15 Sep 2018 22:31:32 +0200 Organization: my virtual residence Message-ID: <87ftya7ba3.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537051048 27738 195.159.176.226 (15 Sep 2018 22:37:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2018 22:37:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: spacibba@aol.com, Joost Kremers , Noam Postavsky , emacs-devel@gnu.org, 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 Sun Sep 16 00:37: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 1g1JBp-00075p-FY for ged-emacs-devel@m.gmane.org; Sun, 16 Sep 2018 00:37:21 +0200 Original-Received: from localhost ([::1]:56965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1JDv-0003iU-Ma for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2018 18:39:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1JCo-0003h4-Sr for emacs-devel@gnu.org; Sat, 15 Sep 2018 18:38:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g1JCn-0002Oy-Ns for emacs-devel@gnu.org; Sat, 15 Sep 2018 18:38:22 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::10]:24435) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g1JCk-0002C7-BE; Sat, 15 Sep 2018 18:38:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537051097; 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=JMoUaCXdWlnr9epLaHuCvvXD25rx6sG9tjM4OYA2IaI=; b=UFmbi8uQ+xLLkS7BAKEjLtswWuwzvNHHOqNF/HwxsxnuCHqUjrgAIEFisfILezj60I OKi7CB2bXtE31bBgsC3S15HDhD8WpV3qQc5oYW2ahpD9W3gOTtd3wsNk6AC+8Q4KcIVz xPEYYsV3oqmDaaeW8PRY3rfq3/JCPwK6C17FbaGUweBfTStzhnbQsHXaxaBVEvX5yQ55 aTsWZxJmU4tM4xcA/3Y9ByrEVdCrnG8vpldRHd0no8bzujsiFFSIJs9qwvu5hq6VBtWn aC/f/Im+4eSmFOBfX9ZpKip1MP2wOo15+WLvwbWQKnhXzv7l9DDEfpCfSOUaKjNFSykB B4/Q== 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 20bdb7u8FMc76D2 (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:07 +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 1g1JCZ-0001LX-5d; Sun, 16 Sep 2018 00:38:07 +0200 In-Reply-To: <20180914104833.GA4103@ACM> (Alan Mackenzie's message of "Fri, 14 Sep 2018 10:48:33 +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::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:229827 Archived-At: Alan Mackenzie writes: > [...] >> >> Then how come I can't even see where the mark is, let alone the region? >> >> Why is that not displayed? > >> > Because this was tried and found counter-productive. > >> It would be very helpful and not counter productive at all. > > Please, I'm am telling you what others found by experience. So transient-mark-mode is counter productive --- strange that it did become the default. Unfortunately, it wasn't implemented with consistency and not all the way through. >> >> When highlighting screws up your syntax highlighting, maybe a different >> >> way of highlighting could help. Even only marking the fringes of lines >> >> that are selected would be better than nothing. > >> > I prefer nothing, thanks. Would you want to make my preferred way of >> > working impossible? > >> No, it only doesn't make any sense to pretend that there is a selection >> when there is actually none. > > This may be your main problem. The concept of "selection" doesn't really > exist in Emacs as such. So your desire for there either positively to be > a selection or not be a selection at any given time doesn't really make > sense. It makes perfect sense, and it's how I'm using Emacs. What doesn't make sense is these hidden regions, the impossibility of making a navigational aid visible, the ability to do stuff with selections without them being selected and the messing up of navigational things with making selections. > In Emacs there is point and (usually) mark, which delimit the > region. If you want to regard the region as being "the selection", you > can, but if you try to extend that to "there always being a selection", > you run into conceptual trouble. That's what I think has been happening, > here. So you see how the concept of regions doesn't make sense and could use an overhaul. >> It gets even worse when Emacs pretends that there is a selection when >> there is actually none only because the user once had to set a mark >> somewhere to make a selection and would have to kill the whole buffer >> to get rid of the mark and thus the pretended selection. > > In Emacs there is the region, as I said. Pretending, or just assuming, that there is a selection when there is none is a bad idea. Imagine I select a line, copy it, move to another place and paste it. Emacs assumes that there is a selection I can do stuff with, like copying and deleting or narrowing the buffer to it. If I make a mistake and press the wrong key, Emacs acts on this assumption and messes up my file. That's a design flaw. This isn't useful for navigation, either, because when I yank, Emacs randomly sets the mark somewhere else. So if I wanted to go back to from where I copied the line, I'd be better off to have set a bookmark or a register first. I could press C-x C-x and get the copy of the line I just created selected, and that's useless because I already copied that line. This pretending/assuming is not useful for anything but making mistakes worse. > [...] > >> >> > There are many advantages to having transient-mark-mode disabled: >> >> > primarily simplicity, and the severe reduction in the modal >> >> > behaviour (in the sense of key sequences doing different things in >> >> > things like vi's insert mode and command mode). And I'm not happy >> >> > having my font-locking splatted by the region's highlighting. > >> >> Any simplicity here is no more than a deceptive apparition. > >> > :-) No, the simplicity is real. > >> There is no simplicity. > > I'm telling you my experience, I'm not making things up. Why do you > think I disable transient-mark-mode in my Emacs, then? I think it's because you dislike any other highlighting than what you already have so badly that you make things hard for yourself by not being able to see what you have selected and by forcing yourself to having to go to lengths when you need to limit functions to a selection. I don't understand why you need to read the part you have selected for the few seconds it takes to do something with it in perfect highlighting. You could simply read it first and then select it. You don't need to read it while you make a selection, but you could finally see what you're working with. > [ .... ] > >> None of the options would do what I want, and making an extension that >> does what I want isn't really an option, either. > > Enabling transient-mark-mode and setting mark-even-if-inactive to nil > gives you what you've said you want, I think. Partly --- it still doesn't decouple the mark from making selections so it could be used for navigation. What it seems to do is to require the selection to be highlighted when you want to do something with it. It's description is a bit weird: ,---- | Non-nil means you can use the mark even when inactive. | This option makes a difference in Transient Mark mode. | When the option is non-nil, deactivation of the mark | turns off region highlighting, but commands that use the mark | behave as if the mark were still active. `---- What does 'using the mark' refer to? I'm not using the mark, it's for navigation and can not be used for that while it is broken by being coupled to making selections. The description doesn't say what it means when mark-even-if-inactive is nil, and the 3rd sentence kinda repeats what the first one said, but it doesn't seem to be true. Query-replace definitely doesn't behave as if the region were still active when mark-even-if-inactive is non-nil. Maybe this is better: ,---- | This option makes a difference in Transient Mark mode. When the value | is nil, doing something with a hidden region is not possible. When | the option is non-nil, commands that do something with a hidden region | work as if transient-mark-mode was disabled. `---- I don't know what effect it has on active regions and what it does when transient mark mode is disabled, though. >> Again, this stuff needs an overhaul. > > I don't think you've managed to persuade anybody, certainly not me (yet). Well, you got an example above with mark-even-if-inactive: What does it actually mean, and how is all this supposed to make sense? What sense does it make that mark-even-if-inactive is non-nil by default with transient-mark-mode enabled being the default? It should be nil by default because that would make a lot more sense. > Why are you using Emacs at all? You seem to dislike its core concepts > and methods fairly strongly. That some things don't make sense doesn't mean I dislike Emacs. I like it very much, and I think it might be good if it had more users, so I'm pointing out what doesn't make sense so things can be improved upon. It was suggested to make delete-selection-mode the default because it seems likely that new users might expect the behaviour it provides. I'm going a bit further by saying that making and working with selections could use an overhaul because there are so many inconsistent things involved and that it all doesn't make much sense once you start thinking about it --- and before that is sorted out, changing the default to be d-s-m enabled doesn't seem a good idea. > There are other editors available, some of which will more closely > approximate the way you want to handle selections. Why are you > sticking with Emacs? Which one would be a better alternative?