Re: Shift selection using interactive spec

[Stefan Monnier]

> That's a problem because the current mark in Emacs doesn't
> traditionally behave anything like the beginning of a "shift-selected"
> region.  It's a force fit, at best.   The addition (by transient-mark-mode)
> of an "activated/de-activated" flag is a crude *approximation*
> of what users expect, in a situation where no approximating is
> necessary.   For example, a "right arrow" key-press should simply
> *forget*, more or less entirely, the marker at the start of the
> highlighted region.    That's the default behavior if tentative mark
> functionality is added but it's functionality that would require
> yet more elisp code if transient-mark-mode were to catch up with
> it.

I do not follow you, Tom: how would the right arrow magically forget
your tentative mark?  In what way is that different from setting
mark-active to nil?  I have the strong impression that you do not know
what is the "temporary" form of transient-mark-mode" (this is
a transient-mark-mode that's activated until the region is "consumed")
and neither do you know about the "only" form of transient-mark-mode
(that is a form of transient-mark-mode which is deactivated after the
very next command).

> What users expect, in the traditional GUI paradigm, is a kind of
> mark that doesn't toggle between "activated" and "deactivated" but,
> rather, is always active when present but which commands tend to
> cause to go away entirely.   Let's dub that "the mistake".  The
> mistake is adding an "active" flag instead of a separate tentative
> mark.

In what way is it different, really?  The problem is how/when to
activate/set it and how/when to deactivate/unset it.  Whether it's
a flag or a mark makes no difference.

> It's *because* of the mistake that, for example, Stefan is now
> positing the existence of a formal category of "motion commands"
> that have to be modified to call a function that dynamically
> asserts that they are motion commands.

??? The notion of "motion commands" is needed because the behavior we
want is "when a motion command is bound to a non-shifted key but is
activated via the shifted of that key, we want the motion to select
a region".

Try it in your typical GUI editor: S-arrow will select a region, but S-a
will just insert an upper-case A.

I.e. this need is 100% unrelated to the way the selected region is
implemented and when/how it gets de-selected.


        Stefan