Re: Shift-movement selection

[Thomas Lord <lord@emf.net>]

Richard Stallman wrote:
> Now I understand your proposal.  I don't see how it would handle the
> issue of making non-shift movement commands deactivate the mark, but
> maybe it can be made to do that.
>   

I have accidentally confused things by making, now, three proposals.
Of the three, I particularly like the last.

One proposal is coded almost like i-search as a sorta-kinda
recursive edit.   Non-shift movement commands de-activate
that because deactivation is the default for all commands
which either (a) do not explicitly set a flag otherwise or (b) are
*not* invoked via a shifted keysequence whose binding is
found by defaulting to the unshifted sequence.    That works
but the third one is simpler.

Proposal #2 is similar to #1 but hairier, using minor mode
foo to .... nevermind... the third one is simpler.

Proposal #3 could be re-expressed as:

    Function: enter-shift-mark-mode
    Install the shift-mark-mode-post-command-hook and record the
    point as the tentative mark.

    Function: abandon-shift-mark-mode
    Toss the tentative mark and remove the post command hook

    Function: seal-the-deal-from-shift-mark-mode
    Turn the tentative mark into a normal mark.

    Function: shift-mark-mode-post-command-hook
    If the last command set the right flag, keep the tentative
    mark.   Otherwise, if the last command was invoked by
    defaulting a shifted key-sequence to non-shifted, then
    again keep the tentative mark.   Otherwise, abandon-shift-mark-mode.

    Function: unbound-shift-key-treat-as-enter-shift-mark-mode
    Remove the shift from the keysequence that invoked this command,
    enter-shift-mark-mode, and process the simplified keysequence.

and various convenience functions related to that basis.  Make
the default binding of various shift keys be 
"unbound-shift-key-treat-as-...."


I think #3 could be the best of the lot.



> However, I tend to think that the use of the special character in
> `interactive' to indicate these commands is a cleaner method overall.
>
>   

Works both ways, here.   The underlying enter-shift-mark-mode could
be bound all by itself to a key or, if some prefer, can be called via
unbound-shift-key-treat-as-enter-shift-mark-mode.

The key thing is getting the "semantics of the mark ring" right.
The mistake we've all been making (and me with proposals #1
and #2) is to think that shift-mark state has to be in the command
loop.   Instead, it's a 1-bit flag for the top of the mark stack: the 
distinction
between a normal and a "tentative" mark, where "tentative" marks only
ever occur on the top of the mark stack.


-t



>
>