RE: Mark set by ?mark-*? not deactivated by point motion

[Drew Adams]

> I'm more wondering about why you'd mark a word with M-@ only to
> immediately afterwards deactivate the region.
> 
> I never use M-@ but I use C-M-SPC all the time, and very often I do
> C-M-SPC (maybe repeated a few times) followed by some cursor motion
> (including C-x C-x sometimes) to "fine tune" the boundaries of the
> active region.
> 
> So I rely on this behavior very frequently and I find it rather
> convenient not to have to re-activate the mark explicitly when I'm done
> tuning its boundaries.
> 
> On the contrary, I find the deactivate-mark behavior of
> "navigation after shifted-navigation" to be a mis-feature: it forces me
> to be careful to keep the shift key pressed until I'm really done
> setting up the region and it prevents me from using navigation commands
> which I can't use in a shifted form (or which don't (yet) support
> shift-select-mode).  I don't mind very much, tho: I just use C-SPC
> instead, but I think in terms of UI, navigation should never deactivate
> the mark.
> 
> I have the impression that this behavior was simply copied from other
> applications, and those don't have something equivalent to Emacs's C-g,
> so their users are used to making a dummy un-shifted cursor movement
> when they just want to deactivate the selection.  But in Emacs we have
> C-g for that.

I can see both points of view. The behavior objected to here by
Yuri is fairly standard in Emacs, but Emacs does not follow it
everywhere.

A case where the behavior follows instead what Yuri expects for
this is selecting text with the mouse (in any way: double-click,
mouse-1 then mouse-3 etc.). In this case immediately subsequent
cursor motion does deactivate the region.

Whether Emacs should be consistent in this regard, I don't know.
But apparently Emacs presumes that if you use `M-@' to select a
word (put the active region around it) then you intend cursor
motion to extend it. And apparently it presumes that if you
double-click  mouse-1 to select it then you do not intend cursor
motion to extend it.

A guess is that the latter choice is because it presumes that you
will use only the mouse to extend it. That's not bad reasoning,
I think, but it does make for some inconsistency, so maybe it
can confuse some users.

I tend to like the existing behavior, FWIW. But especially in
cases where there is no mouse equivalent I think it's helpful
to be able to use keyboard and mouse together indifferently.
In that context, see bug #32747.