RE: can a command specify overwrite selection behavior?

[Drew Adams]

> how many functions actually use the delete-selection property,...
> Am guessing, these days, if elisp programer want the behavior of
> deleting existing text selection in commands they write, a reliable
> and easy and explicit way is simply to put in the code...
>     (delete-region (region-beginning) (region-end)))
> instead of relying on delete-region property.

Yes, if you just want to delete the region in Lisp code, use `delete-region' (or
`kill-region' if you want to put it on the `kill-ring').

Property `delete-selection' is only for `delete-selection-mode'.  (But nothing
prevents anything else from (ab)using it.)

Delete-selection mode is for _interactive_ deletion of the active region.  In
particular, it is for use by _keys_ bound to commands that are associated with
the `delete-selection' property.

That's the aim of delete-selection mode, IMO.  The idea is not to delete the
region whenever the particular command (function) is invoked, or even whenever
it is invoked interactively (as witnessed by your `M-x' trial).

The idea is to make certain _keys_ delete the active region before doing what
they would otherwise do.  It's about interactive editing using keys.  In
particular, it's about letting new text you type overwrite text you have
selected.

You tried testing your command `insert-date' wrt property `delete-selection' by
using `M-x'.  That's not how delete-selection mode is used (intended to be
used).  The behavior surprised you in your testing, but that was only because of
misunderstanding how `M-x' and `delete-selection-mode' work.

The behavior of _keys_ bound to commands that have a `delete-selection' property
is generally _not_ surprising.  When you tested your command the way users would
presumably use it (bound to a key), you saw that it works.

> I think elisp function property is rather esoteric (e.g. it is
> not a feature in most langs,

Lots of things in Lisp are not features in most languages.  Symbols (in the Lisp
sense) are among them.

In OOL you don't think it is weird for an object to have attributes or
properties, or to have certain possible behavior definitions attached to it.
Well, that's the kind of thing that's going on with Lisp symbols.

Symbols are particular kinds of objects.  They can have various properties (in
the general sense, some of which are symbol properties in the Lisp sense): name,
function cell, value cell, property list of additional (including user-defined)
properties.  In general, the value of a given symbol property can be any Lisp
value.

> would you advice to actually make use of the delete-selection
> proprety or just use the explicit code above?

The `delete-selection' property is for `delete-selection' mode.  My
recommendation would be to use it only for that, its original purpose.  It
provides a way of attaching particular additional behavior (delete/kill the
active region) to particular commands.

Not every command has an associated symbol (a command can be anonymous), but for
a command that is the value of a symbol's function cell, that symbol can serve
as a handy place to attach info that you ultimately want to associate
(indirectly) with the command.

Delete-selection mode uses property `delete-selection' to define some
additional, region-deleting behavior to associate with a command.

That use of a symbol property is one way to modify a command's behavior in a
predefined way (limited choice of predefined behaviors defined by delsel.el).
There are other ways to modify a function's behavior, of course, including
`defadvice'.

Instead of attaching the behavior change to a command in order to manifest it
for a key, one could imagine attaching it more directly to the key.
Delete-selection mode is one way to get the job done of making certain keys
delete the active region.  One could imagine other ways.  There is nothing
sacred about delete-selection mode.

Symbols and symbol properties are powerful parts of Lisp.  But to use them you
need to keep in mind that a symbol and its function-cell value (and the other
property values) are not the same thing.  Similarly, a command and a key that it
is bound to are not the same thing.

Because of these differences there are lots of possibilities of dynamic
attachment, lookup, indirection etc.  And whenever there are such differences
there is also the possibility of a mismatch or confusion.

Add to this the historical/time component of user interaction (command history),
and you get even more possibilities for mismatch/confusion.  Add in the use of
hooks and you get still more.  The more possible attachment points, the greater
the possibility of inappropriate attachment or detachment.