Re: Shift selection using interactive spec

[Chong Yidong]

Stefan Monnier <address@hidden> writes:

>>> Shouldn't we just get rid of those special cases "to speed up the cases
>>> that are plenty fast anyway"?
>> Not sure what you mean.
>
> Something like the patch below.

The comments in the redisplay code suggest that this optimization is
important.  If the code isn't harming anything, why remove it?  At the
very least, maybe you should ask Gerd what the impact might be.

>> I'm assuming we want to preserve backward compatibility re the meaning
>> of `only' and `identity' for transient-mark-mode.  I'm not sure if
>> there are external packages using these.
>
> I don't think this backward compatibility is important: these are fairly
> recently introduced values and they're only used in unusual corner cases.
>
>> (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.  This
is because there is simply too large a body of code, both inside the
Emacs distribution and elsewhere, that treats a non-nil value of
transient-mark-mode as "operate on the region instead".

>> If the user runs any other command, it is supposed to deactivate the
>> mark/unhighlight the region.
>
> Maybe for most commands, but maybe not all.  If all(most) non-shifted
> movement commands turn it off explicitly (as I suggested above), and
> given that all buffer modifications already turn it off, there isn't
> much left and those left may actually be better off *not* turning the
> selection off.
>
> I first want to try this, and only if it causes actual problems will
> I want to try something else.  The "only" form is too fleeting and tends
> to disappear for the tiniest reasons.  I prefer a region that
> occasionally stays ON when we don't want it than one where you feel like
> it might disappear from under you at any time.

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.

I've been thinking about cases where you might want the shift-selected
region to persist after a command.  The only good example I can find
is M-x eval region, which doesn't deactivate the mark in tmm.  But
even in this case, the advantage either way seems to be marginal.  If
you care enough about keeping the mark active, why not use C-SPC in
the first place?

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.