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: Sat, 15 Sep 2018 10:20:16 +0000 Message-ID: <20180915102016.GA15443@ACM> References: <87d0tihxzw.fsf@toy.adminart.net> <20180913174640.GB4019@ACM> <8736udkuit.fsf@toy.adminart.net> <20180914104833.GA4103@ACM> <83k1nojgia.fsf@gnu.org> <7bed1f76-5bae-44cb-9b22-206b513043be@default> <83d0tfkj77.fsf@gnu.org> <1c393214-c186-4760-9a37-e0450c946446@default> <83zhwji4hx.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1537006893 14819 195.159.176.226 (15 Sep 2018 10:21:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2018 10:21:33 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, Drew Adams , phillip.lord@russet.org.uk To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 15 12:21:28 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 1g17hf-0003ig-F4 for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2018 12:21:27 +0200 Original-Received: from localhost ([::1]:54956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g17jl-0007Pt-QJ for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2018 06:23:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g17jc-0007Pk-QD for emacs-devel@gnu.org; Sat, 15 Sep 2018 06:23:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g17jZ-0003gw-JD for emacs-devel@gnu.org; Sat, 15 Sep 2018 06:23:28 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:48842 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1g17jZ-0003fF-CK for emacs-devel@gnu.org; Sat, 15 Sep 2018 06:23:25 -0400 Original-Received: (qmail 85434 invoked by uid 3782); 15 Sep 2018 10:23:24 -0000 Original-Received: from acm.muc.de (p5B14674C.dip0.t-ipconnect.de [91.20.103.76]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 15 Sep 2018 12:23:20 +0200 Original-Received: (qmail 15981 invoked by uid 1000); 15 Sep 2018 10:20:16 -0000 Content-Disposition: inline In-Reply-To: <83zhwji4hx.fsf@gnu.org> 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:229809 Archived-At: Hello, Eli. On Sat, Sep 15, 2018 at 10:50:18 +0300, Eli Zaretskii wrote: > > Date: Fri, 14 Sep 2018 13:57:59 -0700 (PDT) > > From: Drew Adams > > Cc: yurivkhan@gmail.com, acm@muc.de, hw@adminart.net, spacibba@aol.com, > > joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, > > phillip.lord@russet.org.uk [ .... ] > My point is that even users who know what they are doing currently > have no good means to tell that to Emacs on a case by case basis. If > they turn on transient-mark-mode, they get a whole slew of non-trivial > behaviors as a single package deal; if they turn on > delete-selection-mode, they have another package deal which > contradicts some of the one they get with transient-mark-mode. > My proposal is to give users a more fine-grained control of that, so > that users could control the "meaning" of the current region with > easily typed commands, and by that tell the next command(s) how to > interpret the region. The implementation of this proposal could be > based on a new "state" of the region, which will be the 3rd state in > addition to the currently-available "active" and "inactive" states. > The 3rd state will have the semantics of supporting the behavior > provided by the commands that have the delete-selection property on > their symbols. Or it could be based on something else. The important > facet of the proposal is that we need to introduce easily typed > commands that will assign one of the 3 possible meanings to the > current region. > With that, users will have the capability of using delete-selection > features when they need them, without deciding up front that they > prefer those features to other commands that pay attention to active > regions. We could also teach the commands which could support either > behavior to DTRT by default using some heuristics. All of this and > more is currently impossible because the same state of the region is > interpreted differently by some commands given a global mode. I can't help feeling that this isn't the right approach. I feel that it will increase complexity which the new features won't justify. I know I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here, but still: I think having to press a key sequence before d-s-m would work would take the purpose of d-s-m away - that key sequence might as well be C-w. You seem to be proposing to associate a three-value state with the region, which state users could change with key sequences. I can see this being more confusing than the current two-value state (or is it 2.5?) we currently have. It might well be that, having introduced transient-mark-mode as a default, a certain degree of confusion in Emacs is unavoidable. If so, does it make sense to spend a lot of effort which might merely switch the confusion to somewhere else? Assuming that we'd want to have options to retain all the "old" behaviour, I think it would be difficult to avoid increasing the confusion. I've interacted somewhat with hw, who's been driving this thread, and come to the conclusion that he doesn't really want to use Emacs. The mechanisms of point, mark, and the regions are fundamental to Emacs and can't be readily customised away. I don't think we should try to provide this customisability. Sorry if I've been a bit negative in this post. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).