Re: Shift selection using interactive spec

[Stefan Monnier]

> There are two aspects to the answer:  cleanliness and
> semantics.

> Cleanliness: the three variable proposal needs a *tiny bit*
> of new code in the C part of Emacs.   In exchange, it
> doesn't need transitive-mark or delete-mark... elisp code
> at all (because the default behaviors are better).

Most of the transient-mark-mode is C-level as well.  The "only" form of
transient-mark-mode does pretty much what you suggest.
And no: it's not clean.  The mere fact that you have a "value before
command", "value to set at the end of this command", etc... makes it
brittle in the face of non-local exits and, recursive edits and things
like that.

Besides, I want *less* C code, not more.  Especially for a feature which
I only find relevant for UI-compatibility with other applications.
Using C-SPC + movement is at least as convenient.  You may say it's
a bit more VI-ish since it's modal, but honestly, I think Emacs already
uses more than enough modifiers.

> Cleanliness again:  In the three variable system, most
> commands DTRT by default, even if they remain ignorant
> of the three variables.

We already have that with the pre/post-command-hook implementation in
cua-selection-mode.

> This proliferation of categories is the price for using a binary "active"
> flag rather than the three-variable system.    How are those categories

No, it's unrelated.  It's because I want a different behavior.

Don't take me wrong: the current way transient-mark-mode works, i.e. the way
things are spread between the mark itself, mark-active, deactivate-mark, and
transient-mark-mode, is pretty messy but it doesn't have any impact
about where code has to run, only about how to write the code (which
tends to have to look at more than a single variable).

> supposed to compose, anyway?   That is, if I call a "consuming" command
> as a function, does that make my command also "consuming"?

No, these are all meant to be specifically for `interactive' use.
But it simply depends on where the code is put.  The exact same problem
holds for your proposal.

> Better (more consistent, simpler) is:  "when a command is bound to
> a non-shifted key but is invoked via a shifted sequence, we want the
> shift-select region to remain active during that command".
> There's no need to talk about "motion".

But I don't *want* that generality, which is why I want/need the notion
of "movement command".


        Stefan