Re: Shift selection using interactive spec

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> (If we break compability, we also ought to choose more descriptive
>>> symbol names than `identity' and `only'.)
>> 
>> Then again, we may want to move these special value to deactivate-mark
>> or something like that.  I think we should feel free to rework this bit
>> if the result is cleaner.

> Nevertheless, regardless of the exact details, shift-selection will
> have to end up setting transient-mark-mode to a non-nil value.

Indeed.  I just saw that Miles and Kim were talking about moving the
handling of "only" to deactivate-mark, or something along those lines.

I plead guilty to turning transient-mark-mode into a non-boolean
variable, and would be happy to see it go back to being boolean.

> The way I see it, C-SPC provides a robust region, and Emacs users will
> continue using this even after we implement shift-selection; holding
> down the shift key is too much of a nuisance.  So we're talking about
> how Emacs behaves for new/casual users, who use shift-selection
> because they're either unaware of or unused to C-SPC.  It seems to me
> that such users would expect the shift-selected region to be fleeting,
> since that is the behavior in other editors.  Furthermore,
> shift-selection is *inherently* fleeting, since entering any unshifted
> motion key deactivates the mark, and motion commands are
> psychologically "tinier" (or rather less consequential) than most
> commands.

The way I see it "only-TTM" is a more brittle and less used&tested
implementation than "temporary-TTM", so everything else being equal
I prefer "temporary-TTM".  In this case I'm not convinced the difference
matters, so I prefer "temporary-TTM".

> Now, there is one other example, and that's switching windows.  You
> might argue that it's good to preserve a shift-selected region for
> this, so that it is still there when you return to the window.  But it
> seems to me that the effects of shift-selection and mouse selection
> ought to be as close to equivalent as we can make it (*), and
> preserving a shift-selected region when switching windows is
> counter-intuitive in the mouse selection context.

> (*) The rationale is that if we are going to have more than one set of
>     rules about how the region behaves, it is better to have two sets
>     than three different sets.

That's a valid argument.  So maybe mouse-selection should use
"temporary-TTM" as well (and be deactivated by unshifted movement)?
Then we could get rid of "only-TTM" altogether.


        Stefan