From: Chong Yidong <cyd@stupidchicken.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: Updated proposal for DEL to delete active region
Date: Sat, 22 May 2010 19:40:01 -0400 [thread overview]
Message-ID: <87ljbby08e.fsf@stupidchicken.com> (raw)
In-Reply-To: <611EBC8A88E34310966D561E92C6B1B3@us.oracle.com> (Drew Adams's message of "Sat, 22 May 2010 11:37:18 -0700")
"Drew Adams" <drew.adams@oracle.com> 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.
next prev parent reply other threads:[~2010-05-22 23:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-22 17:44 Updated proposal for DEL to delete active region Chong Yidong
2010-05-22 18:37 ` Drew Adams
2010-05-22 19:02 ` Eli Zaretskii
2010-05-22 20:43 ` Drew Adams
2010-05-22 21:39 ` David Kastrup
2010-05-22 22:14 ` Drew Adams
2010-05-22 21:37 ` David Kastrup
2010-05-22 23:40 ` Chong Yidong [this message]
2010-05-23 0:30 ` Drew Adams
2010-05-23 17:10 ` Andreas Schwab
2010-05-24 21:03 ` Stefan Monnier
2010-05-23 1:33 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ljbby08e.fsf@stupidchicken.com \
--to=cyd@stupidchicken.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).