Re: Shift selection using interactive spec

[Chong Yidong <cyd@stupidchicken.com>]

Stefan Monnier <monnier@iro.umontreal.ca> 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.

> It is ugly right now and this makes it worse.  How 'bout just
>
>    if (CONSP (Vtransient_mark_mode))
>       Vtransient_mark_mode = XCDR (Vtransient_mark_mode);
>
> and then replace `identity' with (t . nil) and `only' with (t . (t . nil)).
> Or something like that?

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.  If we decide not to retain
compatibility, we can remain the part of the code that handles the
case where transient-mark-mode is `only' and `identity' rather than
`(only t)' and `(only nil)', etc.

(If we break compability, we also ought to choose more descriptive
symbol names than `identity' and `only'.)

> Any reason to use `only' rather than to explicitly deactivate the mark
> in handle-shift-selection when this-command-keys-shift-translated is
> (and the region was selected with this-command-keys-shift-translated)?
> Apparently that is the approach that is used in pc-selection-mode and in
> cua-selection-mode, so it seems to work well enough.  The `only' form of
> transient-mark-mode is a bit brittle for my taste (gets broken by
> switch-frame events and things like that), so I'd rather only use it if
> really necessary.

If the user runs any other command, it is supposed to deactivate the
mark/unhighlight the region.  Transient mark mode's `only' mechanism
handles this automatically.  Off the top of my head, if we implement a
separate system for shift selection, making it DTRT would require code
changes at exactly the same places where the `only' mechanism is
already in place.  So I don't see a big advantage in implementing a
parallel system.