From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Updated proposal for DEL to delete active region Date: Sat, 22 May 2010 19:40:01 -0400 Message-ID: <87ljbby08e.fsf@stupidchicken.com> References: <87ljbbbzl1.fsf@stupidchicken.com> <611EBC8A88E34310966D561E92C6B1B3@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1274571613 20495 80.91.229.12 (22 May 2010 23:40:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 22 May 2010 23:40:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 23 01:40:11 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OFyId-0002zs-7m for ged-emacs-devel@m.gmane.org; Sun, 23 May 2010 01:40:11 +0200 Original-Received: from localhost ([127.0.0.1]:33721 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFyIc-0003QJ-LB for ged-emacs-devel@m.gmane.org; Sat, 22 May 2010 19:40:10 -0400 Original-Received: from [140.186.70.92] (port=37135 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFyIW-0003NT-EL for emacs-devel@gnu.org; Sat, 22 May 2010 19:40:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OFyIU-00016q-CE for emacs-devel@gnu.org; Sat, 22 May 2010 19:40:04 -0400 Original-Received: from pantheon-po14.its.yale.edu ([130.132.50.23]:48894) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OFyIU-00016l-AD for emacs-devel@gnu.org; Sat, 22 May 2010 19:40:02 -0400 Original-Received: from furry ([64.134.65.159]) (authenticated bits=0) by pantheon-po14.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o4MNe1Z4025602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 May 2010 19:40:01 -0400 Original-Received: by furry (Postfix, from userid 1000) id 29054C057; Sat, 22 May 2010 19:40:01 -0400 (EDT) In-Reply-To: <611EBC8A88E34310966D561E92C6B1B3@us.oracle.com> (Drew Adams's message of "Sat, 22 May 2010 11:37:18 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.50 (gnu/linux) X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125088 Archived-At: "Drew Adams" writes: > So we now break any existing code that counts on `delete-char' or > `delete-backward-char' being key-bound. In particular, customizations > (e.g. key remappings) involving those commands no longer work. Yes, this is a clear downside. In the absence of backward compatibility considerations, it would be cleaner to separate the function that deletes from the command that deletes. This is similar to the distinction we make between, say, forward-line and next-line. This is not entirely academic. For instance, when overwrite-mode is active, delete-backward-char untabifies while deleting. This behavior is useful when called interactively, but not clean when called programmatically. It could be argued that the benefits are too minuscule compared to the disruption. I would like to hear some arguments either way. If we decide not to go the delete-backward/delete-forward route, there is still the earlier approach I've presented, which changes delete-char and delete-backward-char directly without separating them out. > So instead of having one such var per command (bad), or one var for > all such commands (bad), or using a property on a command symbol such > as delsel does (good), we now have two new commands whose > implementations hard-code this feature (bad). The new commands and > the new option hard-code each other. First, the goal is not to replace delete-selection mode. It's to eliminate the special-case handling of mouse selections and make active selections behave more consistently. Second, a huge number of commands already hard-code specific behavior when Transient Mark mode is active. That's the point of Transient Mark mode. So I do not find this argument persuasive.