RE: can a command specify overwrite selection behavior?

[Drew Adams]

> >> Essentially, I read this as a detailed explanation of the 
> >> way this bug is triggered.  If one understands the mechanism
> >> of this bug so well, why not fix it?  AFAICS, this subroutine
> >> is placed in a wrong hook; it should be executed later...
> >
> > What bug?
> 
> One discussed in this subthread.

You read the thread wrong, IMO.  No bug.

> > What subroutine?  What hook?  What should be executed later than
> > what?
> 
> Can't answer these questions: the posted code is not complete.

Do you mean the snippet from `delete-selection-pre-hook' that I showed?  I'm
sure you know how to find the complete code for it in file `delsel.el'.

> I expect the subroutine you posted is put into some hook.  This hook
> is executed when M-x-handler had no chance yet to change
> last-command/this-command.  Hence the hook should better be executed
> later than this.

If you have a bug to report or you think you have a bug fix or an enhancement
patch, then use `M-x report-emacs-bug'.  The Emacs developers will be glad to
tell you whether they consider it a bug, a welcome bug fix, or a welcome
enhancement patch.

I don't speak for them any more than you do.  But according to Xah, one of those
developers (a certain RMS) already informed him that the behavior he described
is no bug.  One can certainly disagree with the Emacs developers, and I do so as
often as anyone. ;-)  But they are the ones to convince, not me.

> > This behavior is _by design_.
> 
> Could you show me the design document specifying that commands MUST
> behave differently when executed by M-x?

"By design" means on purpose, purposefully, with intention, in an intentional
manner, by choice, deliberately.  And yes, like it or not, most things done by
design are done without any design document.  Did you write a design document
for your mail reply before creating the reply?  Could you show it to me please?
What about a design document for that design document?...

The behavior that was described is part of the intended behavior of `M-x'.  The
purpose of `M-x' includes not only invoking a command but interacting with the
user, on demand.

To that end, `M-x' reads a command, with completion, updates a user-interaction
command history, and does a few other things as well.  Invoking a command is
_one_ part of what it does - one part of what it was designed to do.  `M-x' has
several balls in the air at once.  

That it juggles `this-command'/`last-command' is one (non-trivial) part of its
act.  And yes, anything involving `this-command'/`last-command' is somewhat
limited/fragile.  No question about it.

But if you need a design document to tell that the purpose of `M-x' is more than
just invoking a command then there's probably nothing more I can do for you.  I
pointed out (i.e., admitted) that many of us (i.e., me too) do get tripped up
from time to time and forget this, but when you do think about it it should be
clear.  `M-x' is a UI thing.

At any rate, the original question was about the behavior of
`delete-selection-mode' and why the active region is not deleted when you invoke
a command such as Xah's `insert-date' that is configured wrt `d-s-mode' to first
delete the active region.

I think I answered that.  And yes, it is because of how `M-x' and
`delete-selection-mode' are designed to work - whether or not anyone can find a
design document for either of them.

The code snippet I quoted makes clear the implementation of
`delete-selection-mode' and strongly suggests its design.  The code simply
checks the recorded `delete-selection' property for the value of `this-command'.
That's worth what it's worth, no more.  It is well known that there are
limitations to such a simple approach.  Both `M-x' and delete-selection mode
fiddle with `this-command'; they are both limited by it.

If you want to redesign or reimplement `delete-selection-mode', feel free.  But
its behavior in this case is not some oversight, accident, or mistake, AFAICT.
It is working the way it was intended to work.  And so is `M-x'.

> > Emacs is just doing what it was told to do.
> 
> This is a complete nonce.  EVERY piece of software "is just doing what
> it was told to do".  Still, some are more buggy, some are less.
> 
> Hope this helps, Ilya

Hope it helped you.  I have my doubts that it helped anyone else.