RE: can a command specify overwrite selection behavior?

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

> > This behavior is _by design_.
> 
> No, it's because of the implementation: a pre-command-hook.

To say that (implementation vs design) is to claim that the implementation
somehow mistakes and does not follow the design.  As there is no explicit design
document separate from the code, we cannot make such a distinction.

We can only infer the design and intention from the code itself, code comments,
and some idea about the implementors.  `delsel.el' was written by Matthieu
Devin, a longtime XEmacs developer who worked on the original Lucid Emacs
development.  (I do not know him; I just googled the name from the source file.)

I would seriously doubt that Matthieu was not aware of the subtleties of
pre-command hooks, `this-command', and `last-command'.  My bet is that he opted
for this design with cognizance of any limitations.

Whether his choice is the best one for delete-selection can of course be
questioned, but I see no reason to claim that the implementation does not fit
the design, that he didn't code what he intended.

It appears on the contrary that use of a pre-command hook is the way
delete-selection mode was designed and implemented from the outset.  It is not
some implementation detail that somehow deviates from the chosen approach.  It
is the approach (design and implementation) that was adopted for
delete-selection.

The design could have been different.  And it could always be changed.  But that
was how delete-selection was meant to work AFAICT - with the attendant
limitations of such an approach (which I pointed to).

> That's one of the reasons why I wanted the shift-select code 
> not to rely on this-command and things like that, but be
> triggered by explicit code in the interactive spec.

Arguing that a different approach would have been or would now be better could
be a legitimate argument.  It is not legitimate to argue that this is somehow an
implementation bug, something unexpected or not understood by those who built it
the way they did.  Unless you can show that they didn't know what they were
doing.

I made several references to the limitations of using a pre-command hook and the
inherent problems of simply comparing `last-command' and `this-command'.

That there are such limitations does not mean that the delsel code is not acting
as it was designed.  And it does not mean that delete-selection mode misbehaves,
not doing what its users expect.  It means that those limitations were accepted
from the get-go and are inconsequential for the intended use.

I haven't seen any argument to the contrary, any demonstration that the chosen
design/implementation does not DTRT wrt the intended use.

Every approach has its strengths and its weaknesses.  Late binding, indirection,
procedural attachment, etc. always bring with them possibilities of dislocation
(and sometimes inefficiency), even as they can sometimes offer convenience or
added flexibility.

But let's be clear that delete-selection mode is about the behavior of
interactively using keys to edit text.  That is all that it was meant for AFAIK,
and that is all that the `delete-selection' symbol property was intended for.

Given that as the use case, the existing design does its job quite well.  About
the only real limitation wrt its use case is the inability to use an anonymous
command (since it uses a symbol property).  And that's a negligible case, IMO.

No bug has been shown here regarding delete-selection mode.  The code that Xah
wrote works fine.  He just did not understand that it should be tested the same
way it will be used: bound to a key.  His command shows no behavior that its
user would find surpising or unwanted, assuming that it is intended to be
invoked from a key.

It is not a _bug_ that you do not always and necessarily see the same behavior
invoking or evaluating something using `M-x' or `M-:' or `pp-eval-expression' as
you do invoking or evaluating the same thing non-interactively from Lisp.  These
are different things, and it is normal that they can sometimes have different
behavior.

That was the question raised in this thread: whether it is a bug that `M-x
COMMAND' can sometimes behave differently from COMMAND invoked from a key
binding.  In particular, a command with a `delete-selection' property.

Delete-selection behavior is not intended to be used from `M-x'.  That would be
silly - I see zero argument supporting such a use case.  No design bug here; no
implementation bug.