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: Wed, 19 Sep 2018 22:36:13 +0200 Organization: my virtual residence Message-ID: <874lelcjia.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> <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> <835zz2f0ub.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537389696 4615 195.159.176.226 (19 Sep 2018 20:41:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Sep 2018 20:41:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 19 22:41:31 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 1g2jHr-000140-10 for ged-emacs-devel@m.gmane.org; Wed, 19 Sep 2018 22:41:27 +0200 Original-Received: from localhost ([::1]:47221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2jJx-0003vD-Mx for ged-emacs-devel@m.gmane.org; Wed, 19 Sep 2018 16:43:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2jID-0002Ab-PH for emacs-devel@gnu.org; Wed, 19 Sep 2018 16:41:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2jIC-0000FV-GB for emacs-devel@gnu.org; Wed, 19 Sep 2018 16:41:49 -0400 Original-Received: from mo6-p02-ob.smtp.rzone.de ([2a01:238:20a:202:5302::12]:26386) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g2jIC-0000ED-6y; Wed, 19 Sep 2018 16:41:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537389706; 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=M9fEU3NhHcf+S6Eg7ff1+h3TSj+SCjQKZFh93pPHCiY=; b=pQjBJEjQ9c7kV89NZs8s2M1KdoDMhpZX0xenwfvBR21DlgcBSM7Dwe8QR4MfW5OLTl 6qa+hH3U3+kZMQT3PenhTnGDGMjLURDgjafrCVklsphkiLSUHW0qZptSb8hvUWHxisij JBXtb1ZOBGg4OmTf5iZndyftUg8ST84CoaPZkAAB8F04V+ulY7f0Klu35ngs0yfshONq IaRWUBLy4XD2L6JIM56FIDKZzS4gr4NuL0ukvw8ALUtWGNI9OxWqJHpym1YHzGgaiCrW gxwVijWbIRuq3wDT5xhumkvezQNewUyTflo6XvqvKX/mXIcuruIfResPxUQatA2o5IhD yKlQ== 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 20bdb7u8JKfeKRg (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); Wed, 19 Sep 2018 22:41:40 +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 1g2jI4-0000la-BQ; Wed, 19 Sep 2018 22:41:40 +0200 In-Reply-To: <835zz2f0ub.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 19 Sep 2018 09:38:52 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5302::12 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:229971 Archived-At: 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: 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. They could just work with the selection instead. >> >> > 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. Is the implementation relevant for the distinction? The distinction between a region and a selection exists regardless of the implementation of each. >> 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. ok >> 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. The meaning of these states can vary through different behaviour resulting from changes to variables like delete-active-region and mark-even-if-inactive. These changes go so far as to make for different defaults on their own. A command that glides through all possible combinations of states and/or all possible defaults may have so many combinations to glide through that it would be troublesome to use. But if states/defaults could be stored in registers, users could quickly switch between those relevant for them. >> > 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. What would be an example for this? > 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.