An idea:  Shift-select has pretty close to the same
"semantics" as recursive edits, when viewed from
the point of view of an emacs interaction loop.
So, use a mechanism pretty close to recursive edits
to implement shift-select.   Two variations on the
idea are given here.   One that does in fact have a
recursive command loop;  a second that fakes having
a recursive command loop using minor modes:

In the default key-maps, bind all shifted keys to a single
command we can call enter-implicit-select-mode

That command essentially begins a recursive edit:

enter-implicit-select-mode should first remember where
the point is starting from, then recursively call the
command that would have been invoked without
the shift (this may require reading more keys from the
user).

enter-implicit-select-mode should then read
key-sequences, mapping them the usual way
in key maps, but examining the function to be
invoked before invoking it.   If the mapped
function is, again, enter-implicit-select-mode
then don't recurse but do look up the unshifted
binding and call that interactively.   If the
mapped function is some other function,
then directly call that function interactively,
but immediately return from enter-implicit-select-mode's
recursive edit afterwards (terminating "shift select").

Commands for cutting, copying, wiping, yanking
etc. would still need to be handled specially and
might benefit from some separate mechanism for
telling enter-implicit-select-mode to not exit its
loop, yet.    In other words, a small number of commands
can be modified to continue shift-selection even if they
are not invoked by a shifted key-sequence.

Some modes might already have shift-bindings that
conflict with this.    Oh well, those need individual
attention anyway.

Recursive edits, as described, might not be quite
right.   A similar effect could be achieved with
minor-modes, I think.   A "ghostly" minor mode
could have no extended key-sequences and map
*all* keys to a function saves up the list of keys
pressed so far until they map to a binding in the
underlying keymaps of the buffer (then call the
right commands interactively, adjust whether shift-select
is going on, possibly de-install the ghostly minor mode,
etc.)

Either way, one advantage might be that nothing
is particular "shift specific".   A user who prefered
"hyper-select-mode" (or whatever) could have that
and the same mechanisms would still work.

Another advantage is that most commands would
not need to change.   

Another advantage is that, while this approach does
*slightly* change the way input key-sequences
invoke commands, it's really a very slight change
and mostly transparent to users.

A practical advantage is that it would probably
"mostly work" and almost never fail or surprise
in horrible ways.    It does (I *think*) 80% of the
job "for free" and then makes it easy to go and
patch up the remaining annoyances "by hand" as
they come to attention.

-t


Kim F. Storm wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>   
>>     Why not introduce an after-move-hook, somewhat akin to after-change-hook?
>>
>> If the idea is that Fgoto-char and other point-setting primitives
>> would call this, that would be hard to implement safely and it slow
>> down Lisp programs terribly.
>>     
>
> Maybe the idea is to simply call the hook if point after executing the command
> is different from the value before the command.  It may be useful, but
> I'm not sure it will do the trick... for the shift-move function.
>  
>