RE: delete-selection-mode

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

> And I think relying on ... symbol names (as is done currently by
> d-s-m) is wrong: the behavior should depend on the actual 
> command, so it needs to be part of the command's definition,
> which basically means part of its interactive spec.  Again, the
> reasoning is exactly the same as the one that lead to the "^"
> for shift-select.

That reasoning was somewhat controversial and not very conclusive. I just looked
again at that long thread ("Shift selection using interactive spec" from 2008).
There were some good arguments on both sides (and there were more than 2 sides).
It's good to keep in mind the pros and cons, and not just consider this
simplistically as a closed question.

See what Kim, Juri, and others said, to understand why it can be important to
support symbol properties in addition to coding the behavior in the command's
`interactive' spec.

As Richard put it: "I think we should support both ways, but prefer the
interactive spec". IOW, (a) `interactive' spec and (b) function symbol
properties.

(a) is good for specifying the default behavior of a command: it gives the
command's own, a priori view of its intended behavior. (b) is good for
specifying alternative, additional, or otherwise custom behavior for the
command, as determined by the particular runtime context.

Using symbol properties in this way is, well, as Lispy as you can get. Making
the command's definition the be-all and end-all is akin to hard-coding the
behavior once and for all - it is not particularly Lispy. (But yes, it is
cleaner - Lisp has never been a paragon of cleanliness.) 

A string `interactive' arg means the earliest possible binding of the behavior:
at command definition time. In principle, using `interactive' with a non-string
arg allows plenty of flexibility (later binding of the interactive behavior),
but it still relies on defining the (runtime) behavior in terms of a foreseen
context.

Letting the context influence the behavior in unforeseen ways means still later
binding, and one reasonable way to do that is via the command's symbol
properties.[*]

But no, that is not foolproof. A function is not a symbol, and in Emacs Lisp
there is no way to attach a property to a function itself. And if a function
symbol with a property is bypassed then behavior can be inconsistent. That is
nothing new.

But people have been attaching properties to function symbols since Lisp-Day 1
as ways of controlling behavior in different ways depending on the context. And
Emacs itself does this all the time.

And even the `interactive-form' symbol property is manipulable this way - with
the same possibility of inconsistency (e.g.
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg02575.html).

Here is one piece of that 2008 thread, from Kim, to give an idea of the debate.
The point is that things are not as definitive as you present them.

> That's the beauty of CUA's command property approach - you can fix
> it simply by setting a property on the problematic commands in
> your own .emacs -- no need to mess inside the source code.
> 
> And it is the same for the delete-selection feature -- you can
> make external packages delete-selection aware simply by setting
> a suitable property.
> 
> I.e. if someone complaints that package xxx doesn't work, it is
> much easier to tell them to "add these two lines to your .emacs"
> rather than "you need to find file xxx.el and edit the interactive
> spec of commands xxx-forward and xxx-backward, and then byte-compile
> the file".
> 
> But I've given up already - it seems that most people making decisions
> on this issue don't use shift-select or delete-selection themselves,
> and they are not interested in listening to those who use it and have
> proven experience in implementing it (and having spent a lot of time
> making it work very well).


[*] Advising a command provides even later binding and even more flexibility
than does using properties set on its function symbol. And it is consequently
even less foolproof and more problematic.

Using predefined symbol properties is midway along the spectrum, with
`interactive' string arg near one end and things like `defadvice' near the
other.

It adheres to a predefined framework of known symbol values and their
corresponding behaviors, but it separates (1) the binding of those behaviors to
particular commands from (2) the internal definitions of those commands. And the
predefined framework itself is extensible (without needing to modify existing
command definitions).

Yes, anytime you intentionally separate things this way, defining some of the
behavior here at this time, and some of it over there at that time, you
introduce the possibility of a disconnect, and you can increase the
code-maintenance burden. That's the price of flexibility. Nothing new.