RE: Updated proposal for DEL to delete active region

["Drew Adams" <drew.adams@oracle.com>]

> + ** New commands delete-forward and delete-backward.
> + C-d and DEL are now bound to these commands, instead of delete-char
> + and delete-backward-char.

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.

And what about `backward-delete-char-untabify'?
To cite Stefan (who got the untabify name slightly wrong):

>> But this doesn't seem right: we're not going to have one
>> such variable for delete-backward-char, delete-char,
>> delete-backward-char-untabify, and the handful of other commands
>> that grep "'delete-selection 'supersede" lisp/**/*.el
>> indicate will want a similar treatment.

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.

Flexibility and legacy out the window.  Might as well stuff users in a sack, tie
it tight, and dump it overboard.


> * Incompatible Lisp Changes in Emacs 24.1
> 
> + ** mouse-region-delete-keys has been removed.
> + 
> + ** delete-backward-char no longer untabifies in overwrite mode.
> + The new command `delete-backward', which is intended for interactive
> + use, does so.

Those might be the only incompatible vanilla-Emacs code changes for this, but
they are not the only incompatible changes that can affect Lisp code (including
user code).  Basic, traditional key bindings are changed.  Any Lisp code that
expects those is now broken.


Why do this by defining new commands and changing existing key bindings?

Why not just attach a property to any existing command symbols that you want to
become sensitive to this new feature?  That's the way `delete-selection-mode'
does this sort of thing.

Oh yeah, I remember: you guys don't like attaching properties to command
symbols...  The delsel and thingatpt treatment is a saner approach, IMO.  Yes,
it's true that symbols are not functions and not all functions are associated
with symbols.  It's still saner.