emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shift selection using interactive spec


From: Lennart Borgman (gmail)
Subject: Re: Shift selection using interactive spec
Date: Mon, 17 Mar 2008 18:21:05 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

Chong Yidong wrote:
The way I see it, C-SPC provides a robust region, and Emacs users will
continue using this even after we implement shift-selection; holding
down the shift key is too much of a nuisance.  So we're talking about
how Emacs behaves for new/casual users, who use shift-selection
because they're either unaware of or unused to C-SPC.  It seems to me
that such users would expect the shift-selected region to be fleeting,
since that is the behavior in other editors.  Furthermore,
shift-selection is *inherently* fleeting, since entering any unshifted
motion key deactivates the mark, and motion commands are
psychologically "tinier" (or rather less consequential) than most
commands.

I think that for those of us who are very used to shift-selection there must still be ways to avoid deactivating the mark with certain move commands. If for no other reason because keyboard looks quite different. (For example, to type M-> I have to use the shift key. Though admittedly I have never used that one ...)

I would rather restrict dectivation to those keys that deactivates region in other applications. (Plus C-g etc of course.)

I've been thinking about cases where you might want the shift-selected
region to persist after a command.  The only good example I can find
is M-x eval region, which doesn't deactivate the mark in tmm.  But
even in this case, the advantage either way seems to be marginal.  If
you care enough about keeping the mark active, why not use C-SPC in
the first place?

Replacing things in various ways in a region seems like good candidates.

Maybe there should be a way to say "don't deactivate the mark after next command whatever it does"?

Now, there is one other example, and that's switching windows.  You
might argue that it's good to preserve a shift-selected region for
this, so that it is still there when you return to the window.  But it
seems to me that the effects of shift-selection and mouse selection
ought to be as close to equivalent as we can make it (*), and
preserving a shift-selected region when switching windows is
counter-intuitive in the mouse selection context.

Wouldn't it be troublesome to keep the region when switching windows when the new window contains the same buffer with a different window-point? (Maybe at least a warning question in such cases?)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]