Re: Files in wrong subdirs of emacs/lisp?

[storm@cua.dk (Kim F. Storm)]

Richard Stallman <rms@gnu.org> writes:

>     We already have both pc-selection-mode and cua-mode doing the
>     same thing, so IMO s-region is obsolete.
> 
> The behavior of cua-mode is very different from the behavior
> of s-region, so we certainly cannot tell users "use cua mode
> instead of s-region."

Yes, s-region has one unique feature (compared to cua and pc-select)
which is that it only shows the region highlight temporarily (for one
second).  But other than that, cua can be customized to just provide
the same functionality as s-region and pc-selection mode.


But there are some fundamental problems with s-region which make me doubt
doubt that anyone is actually using it:

The list of keys which are rebound by s-region is pretty short.  Based
on the feedback I have got from users of CUA, I believe that those who
use shifted movement keys to select a region want such a mode to work
for practically all commands that move the cursor, not just the very
incomplete list provided by s-region.el.

S-region is activated just by loading the file, i.e. it doesn't have a
toggle-mode function with an autoload cookie.  It works by modifying
the global key bindings, and there is no way to turn it off again.

This also means that if some modes redefines these keys in their local
map, they lose their s-region binding (this happens for cua and
pc-select as well, but at least with cua mode, this is *easy* to
handle).

Also s-region uses an awful method of binding all the keys that it
controls to the same function (so C-h k doesn't really work).

> 
> Would a user who uses pc-selection-mode instead of s-region
> notice any differences in behavior?  If so, what differences?

The major difference is that with pc-selection-mode the region remains
highlighted while s-region only highlights it temporarily.  
Also pc-selection-mode has a few more bindings to make it recognize more
shifted movements.

BTW, pc-selection-mode also uses a method of rebinding a lot of keys
in the -mark (shifted) and -nomark (unshifted) state, e.g. S-left is
bound to forward-char-mark and left is bound to forward-char-nomark.
This means that it is non-trivial to add more movement commands to
pc-selection-mode, as you need to write lisp code to do that.  And it
also repeats the doc string for each of the original commands.  

CUA on the other hand doesn't rebind any of the movement keys (it
actually looks for the shift-modifier on user input), and it is
trivial to add more movement commands to be recognized by CUA (via
customize).


My conclusion is that s-region, no matter how ugly it is, has a unique
feature (temporary region highlighting) which may make it useful for
some users.  It doesn't harm to keep it, but I would still make it
obsolete, as I don't think it is something we should actively spend
any time on maintaining it.

Actually, the temporary highlighting of the region is ortogonal to the
shift region selection, so it might be useful to implement that as a
general mechanism based on transient-mark-mode: We could add a
transient-region-highlight-timeout setting which causes the
highlighting of the region to disappear N milliseconds after the last
user command (and shows the highlighting again if the mark is still
active when you execute the next command).  Personally, I would find
that confusing though...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk