Re: Shift selection using interactive spec

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> address@hidden (Kim F. Storm) writes:
>
> > Now, before you settle on a solution, maybe you should also consider
> > how to handle the delete-selection-mode in a sensible way without
> > using the current pre-command-hook + command property approach.
> >
> > Of course, since shift-select is promoted to a standard feature by
> > modifying the relevant commands, we can just take the same approach
> > with delete-selection-mode, i.e. modify the relevant commands to
> > simply honour delsel mode.
>
> There are two possible behaviors:
>
> 1. If transient mark mode is on, activating shift selection should
> resets and activates the mark, and the first unshifted command should
> then return transient mark mode to its original non-nil value.  Thus
> shift selection "stacks" on top of transient mark mode.  I am not
> certain if there is a clean way to do this.  Maybe allow
> transient-mark-mode to take the form of a list?  Any suggestions?

I have right now no suggestion on the implementation, but a comment on 
the behaviour.

This sounds like the behaviour most users would expect from their 
experience in other application. I agree with Thomas that this 
congruence is desirable.

But I think there also must be ways to easily and permanently escape the 
deactivation. For some bindings there is no way to get a shifted 
binding. (An example of this is using % in Viper to move to the opposite 
parenthesis.)

> 2. Shift selection commands activate the mark if it is not active, and
> extends the region if the mark is activate.  Thus [S-right right
> right] would do the same thing as [S-right S-right S-right].  This
> would be rather easy to implement.  Though this behavior sounds
> strange, it actually mirrors the way mouse selection currently works
> in transient-mark-mode.

Such behaviour would be a disaster for manu users, especially new users 
that are used to 1 above.