Re: Shift selection using interactive spec

[Chong Yidong <cyd@stupidchicken.com>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> After playing around with an implementation of this, I feel that it is
>> very problematic.
>
>> The trouble with using handle-shift-selection to explicitly
>> unhighlight the region is that every single motion command needs to
>> call handle-shift-selection, by adding the ^ interactive spec.  For
>> every motion comman (or command that moves point in addition to
>> something else), there will be a bug: the shift-selected region won't
>> be highlighted.  This therefore breaks backward compatibility with all
>> external packages that define their own motion commands.
>
> I do not understand what you mean.  Could you give a sample case?

Suppose we have an external package that defines the motion commands
forward-section and backward-section, which move point forward and
backward by mode-specific amount.  (It might, for example, be rebound
to M-right or M-left.)

In shift selection mode, the first unshifted motion command must
deactivate the mark.  This is the expected behavior.

Now suppose we make the motion commands responsible for deactivating
the mark; for example, by adding an interactive spec code that calls a
function `handle-shift-selection' that checks if the calling key
sequence was shifted, and deactivates the mark if it was not.  If we
start to define a shift-selected region using a shifted forward-char
command, and follow this with an unshifted forward-section command,
the region won't get deactivated.  Instead, it will extend the region.

To fix this bug, we would have to change the external package.

In contrast, it seems to me that there is only a small number of
commands for which we *don't* want to deactivate a shift selection,
e.g. switching windows.  These commands are mostly built into Emacs,
and could be easily modified to DTRT.  That would fix the perceived
fragility of `only' TMM.