Re: Updated proposal for DEL to delete active region

[Chong Yidong]

"Drew Adams" <address@hidden> 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.