From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: delete-selection-mode as default Date: Sat, 15 Sep 2018 10:50:18 +0300 Message-ID: <83zhwji4hx.fsf@gnu.org> 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>> <<7bed1f76-5bae-44cb-9b22-206b513043be@default>> <<83d0tfkj77.fsf@gnu.org>> <1c393214-c186-4760-9a37-e0450c946446@default> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1536997778 23841 195.159.176.226 (15 Sep 2018 07:49:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2018 07:49:38 +0000 (UTC) Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, phillip.lord@russet.org.uk To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 15 09:49:33 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 1g15Ke-00063o-T2 for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2018 09:49:33 +0200 Original-Received: from localhost ([::1]:54658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g15Mk-0002Ke-Vh for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2018 03:51:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g15MW-0002KZ-8E for emacs-devel@gnu.org; Sat, 15 Sep 2018 03:51:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g15MS-0001a2-Uf for emacs-devel@gnu.org; Sat, 15 Sep 2018 03:51:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g15LZ-0006a8-IZ; Sat, 15 Sep 2018 03:50:29 -0400 Original-Received: from [176.228.60.248] (port=2805 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g15LZ-0008MQ-5b; Sat, 15 Sep 2018 03:50:29 -0400 In-reply-to: <1c393214-c186-4760-9a37-e0450c946446@default> (message from Drew Adams on Fri, 14 Sep 2018 13:57:59 -0700 (PDT)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:229805 Archived-At: > 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 > > > > Users can trivially control which of the 5 behaviors to use for > > > a given command, just by putting a property on the command > > > symbol. > > > > Putting properties on symbols to change the behavior of a command is > > not user-level customization. IOW, we are miscommunicating. > > There are users, and there are users. I didn't say that users > will do that in general. Far from it. > > I don't know anyone who has ever bothered to set the d-s-m > behavior for a particular command, unless it's a new command > that they themselves created. Fine, then we agree. The above issue is not relevant to what I perceive as the main problem here: how to give us a way to allow turning on delete-selection-mode without alienating users who have no use for it and very much dislike its effects, in particular when those effects are unintended. > I disagree that there is a problem with d-s-m, or with > turning it on by default. You tout irreconcilability but give > no example. There are plenty of examples in this thread, I see no need to repeat them. > That users can be confused about the region etc. does not > stem from d-s-m - please don't scapegoat it. > > Confusion comes primarily from the introduction of > t-m-m and, especially, the coupling, in C-x C-x, of region > activation with swapping point and mark. There was no > confusion before that. And no confusion was introduced > by adding d-s-m. I didn't "scapegoat" anything. It is immaterial which of the 3 uses of the region is "to blame", because this is not about assigning blame. My description was following the time line: the other 2 uses of the region are already turned on by default, whereas delete-selection-mode is not. It doesn't mean delete-selection-mode is somehow "guilty". > But normally a given user just knows what s?he uses, > and doesn't try to know about and understand every > possibility regarding point, mark, region, selection, > activation, highlighting, action, deletion, etc. 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. > This discussion, since it now deals with all possibilities > (because people who take different approaches have > widened the scope), has made apparent the complications. > > But a given user normally doesn't sense how complicated > this stuff can be. Mr X knows his way of using the region; > Ms Y knows her way, and so on. You assume that there's only one "way" for Mr X and Ms Y. But that assumption is not necessarily true, for experienced users. They will want each of those "ways" in some specific circumstances. For example, "C-x C-x" used as navigation tools doesn't need to activate the region; only the user knows whether that is the case in each specific use case. Similarly, typing a character or DEL when the region is active should replace/delete the region _sometimes_, but not always, and only the user knows which is which. As an experienced user who sometimes needs each one of those features, I would like to be able to control what happens in each case, and turning on and off global modes is too blunt an instrument for that; in particular, the relevant commands are too long and tedious to type. So I'm currently forced to choose just one of these 3 features, the one that gets in my way the least. I would like to be freed from this "one fits all use cases" prison. > You make it sound like things are crystal clear and simple > with the status quo, and that defaulting to d-s-m would > muddy the waters. I said nothing of the kind. See above. > In fact, the waters are muddy now, if one bothers to look > into them. That's exactly what I'm saying. I also suggested one way out of this conundrum. > What's not correct is to suggest that the complications come from > d-s-m. Nothing like that was suggested. And even if it could be somehow understood it was, discussing this particular aspect is a tangent that gets us away from the real issues. Let's not go there just because we can. > It's wrong to suggest that all is harmonious between > your first two region "uses": navigation and invoking > commands on a region, and that your third "use", > delete-selection-mode, is the irreconcilable culprit that > threatens to spit in the soup and turn harmony into discord. There's no such suggestion. Don't feel "offended" on behalf of delete-selection-mode. (And there's no need to say the same thing time and again in so many different ways.) > Defaulting to d-s-m would just make life simpler for > most users (IMHO). And those who don't want d-s-m > on can turn it off. I believe this is a false dichotomy; there's a better solution that would leave more users happy. > You've decided that d-s-m won't be on by default > anytime soon. No such decision was made.