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: Wed, 19 Sep 2018 09:38:52 +0300 Message-ID: <835zz2f0ub.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> <874leq799e.fsf@toy.adminart.net> <835zz5ie17.fsf@gnu.org> <87musg0wyf.fsf@toy.adminart.net> <83va73f0mv.fsf@gnu.org> <87zhwetim0.fsf@toy.adminart.net> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1537339121 24687 195.159.176.226 (19 Sep 2018 06:38:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Sep 2018 06:38:41 +0000 (UTC) Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk To: hw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 19 08:38:36 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 1g2W8B-0006KA-LQ for ged-emacs-devel@m.gmane.org; Wed, 19 Sep 2018 08:38:35 +0200 Original-Received: from localhost ([::1]:43895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2WAI-0002zs-7e for ged-emacs-devel@m.gmane.org; Wed, 19 Sep 2018 02:40:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2W9f-0002y3-HB for emacs-devel@gnu.org; Wed, 19 Sep 2018 02:40:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2W9e-0006Zt-Ef for emacs-devel@gnu.org; Wed, 19 Sep 2018 02:40:07 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2W8T-0004O7-DO; Wed, 19 Sep 2018 02:38:54 -0400 Original-Received: from [176.228.60.248] (port=4622 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g2W8T-0007Yt-0i; Wed, 19 Sep 2018 02:38:53 -0400 In-reply-to: <87zhwetim0.fsf@toy.adminart.net> (message from hw on Wed, 19 Sep 2018 04:26:45 +0200) 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:229962 Archived-At: > From: hw > Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Wed, 19 Sep 2018 04:26:45 +0200 > > Eli Zaretskii writes: > > >> From: hw > >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, > >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, > >> drew.adams@oracle.com, phillip.lord@russet.org.uk > >> Date: Tue, 18 Sep 2018 00:11:05 +0200 > >> > >> >> That would allow to decouple navigation from (making) selections, and > >> >> the concept of a region becomes obsolete, removing all the entanglement > >> >> and greatly simplifying things. > >> > > >> > You forget the kill-ring and the kill/yank commands. Those are almost > >> > exactly identical to what other apps give you with copy/paste, and the > >> > latter use selections. So the reasons Emacs implements selections > >> > using the region are more fundamental than just navigation. > >> > >> What are these fundamental reasons? > > > > They were just described above: the set of commands that copy/kill and > > paste text. > > I don't understand how being able to cut and paste selections becomes > more fundamental than being able to navigate because all of those use > the same fundamental concept. It means if you lose the current meaning of the region, you also lose the cut/copy/paste commands, and their history on the kill-ring. > >> > Once again: in Emacs, selection _is_ the region, and for some very > >> > good reasons. > >> > >> Not to me. The selection is what becomes highlighted when I make one. > > > > That's a minor detail in Emacs. The underlying fundamental > > functionality is the region. > > The distinction between a (the) selection and a (the) region is > important and not a minor detail. For this distinction, it is pretty > irrelevant how both are implemented. This whole thread came to the existent because the underlying implementation is NOT irrelevant. > Do you mean the state to be general, like a default, or to be changed > all the time depending on what a user wants and does? I suppose there > would have to be some kind of default, and if users needed to change it > or to somehow work around it all the time, it wouldn't look like a good > default to me. That's the idea, but since the default should be OK most of the time, the need to override it should be rare. > You could consider transient-mark-mode as a state. How would you deal > with its variations, are they states on their own? For transient-mark-mode, the states are active and inactive. So a command that toggles the state would be something I have in mind. > > No, I mean delete-selection-mode changes the effects of some commands > > in ways that could be very inconvenient in some situations, and > > currently the only way for the user to deal with such conflicts is by > > turning on or off delete-selection-mode. There should be a better way > > of temporarily enabling/disabling delete-selection-mode, similar to > > what we have for transient-mark-mode. > > What if the commands were automatically prevented from having > inconvenient effects? That'd be nice, but I don't believe there's a way to do that without adversely affecting other important features. Hence I propose to place on the user the burden of preventing Emacs from having those inconvenient effects, assuming that each user chooses their defaults such that in most cases Emacs already does what the user expects.