From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: delete-selection-mode as default Date: Fri, 14 Sep 2018 10:48:33 +0000 Message-ID: <20180914104833.GA4103@ACM> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1536922216 22618 195.159.176.226 (14 Sep 2018 10:50:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2018 10:50:16 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: spacibba@aol.com, Joost Kremers , Noam Postavsky , emacs-devel@gnu.org, Eli Zaretskii , Drew Adams , phillip.lord@russet.org.uk To: hw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 14 12:50:11 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 1g0lfv-0005mA-3O for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 12:50:11 +0200 Original-Received: from localhost ([::1]:51021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0li1-0003Uj-GL for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2018 06:52:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0lhK-0003Ty-QO for emacs-devel@gnu.org; Fri, 14 Sep 2018 06:51:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0lhH-0004yX-Ih for emacs-devel@gnu.org; Fri, 14 Sep 2018 06:51:38 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:55473 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1g0lhF-0004x8-KH for emacs-devel@gnu.org; Fri, 14 Sep 2018 06:51:35 -0400 Original-Received: (qmail 80111 invoked by uid 3782); 14 Sep 2018 10:51:30 -0000 Original-Received: from acm.muc.de (p5B147346.dip0.t-ipconnect.de [91.20.115.70]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 14 Sep 2018 12:51:28 +0200 Original-Received: (qmail 4946 invoked by uid 1000); 14 Sep 2018 10:48:33 -0000 Content-Disposition: inline In-Reply-To: <8736udkuit.fsf@toy.adminart.net> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:229774 Archived-At: Hello, hw. On Thu, Sep 13, 2018 at 22:32:58 +0200, hw wrote: > Alan Mackenzie writes: > > Hello, hw. > > On Thu, Sep 13, 2018 at 06:16:24 +0200, hw wrote: > >> Alan Mackenzie writes: > >> > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote: > >> >> Drew Adams writes: [ .... ] > > Don't confuse your personal preferences with objective things. We > > all use Emacs differently, which is why it is so customisable. If > > you can't customise it to work the way you want, that is likely a > > bug, which you should feel free to fix. > Maybe you haven't followed the discussion, which was, amongst other > things, about what should be the default for d-s-m. That Emacs is > customizable doesn't mean that it could be customized to deal with > selections reasonably, and as long as it can't and an overhaul of the > idea of "the region" and making selections might be in order, the > question for a the default of d-s-m can't very well be answered. [ .... ] > > [ .... ] > >> > No, it [the mark]'s central and essential to how Emacs works. There > >> > is ONE region, the part of the buffer between mark and point. Let's > >> > not muck around with this. > >> 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. > >> 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. 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. > 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. [...] > >> > 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? [ .... ] > 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. > Again, this stuff needs an overhaul. I don't think you've managed to persuade anybody, certainly not me (yet). Why are you using Emacs at all? You seem to dislike its core concepts and methods fairly strongly. 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? [ .... ] -- Alan Mackenzie (Nuremberg, Germany).