[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shift selection using interactive spec
From: |
Stefan Monnier |
Subject: |
Re: Shift selection using interactive spec |
Date: |
Mon, 17 Mar 2008 15:11:18 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
>>> (If we break compability, we also ought to choose more descriptive
>>> symbol names than `identity' and `only'.)
>>
>> Then again, we may want to move these special value to deactivate-mark
>> or something like that. I think we should feel free to rework this bit
>> if the result is cleaner.
> Nevertheless, regardless of the exact details, shift-selection will
> have to end up setting transient-mark-mode to a non-nil value.
Indeed. I just saw that Miles and Kim were talking about moving the
handling of "only" to deactivate-mark, or something along those lines.
I plead guilty to turning transient-mark-mode into a non-boolean
variable, and would be happy to see it go back to being boolean.
> 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.
The way I see it "only-TTM" is a more brittle and less used&tested
implementation than "temporary-TTM", so everything else being equal
I prefer "temporary-TTM". In this case I'm not convinced the difference
matters, so I prefer "temporary-TTM".
> 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.
> (*) The rationale is that if we are going to have more than one set of
> rules about how the region behaves, it is better to have two sets
> than three different sets.
That's a valid argument. So maybe mouse-selection should use
"temporary-TTM" as well (and be deactivated by unshifted movement)?
Then we could get rid of "only-TTM" altogether.
Stefan
- what's the point (re shift selection), (continued)
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/16
- Re: Shift selection using interactive spec, Stefan Monnier, 2008/03/16
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/16
- Re: Shift selection using interactive spec, Stefan Monnier, 2008/03/17
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/17
- Re: Shift selection using interactive spec, Lennart Borgman (gmail), 2008/03/17
- Re: Shift selection using interactive spec,
Stefan Monnier <=
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/17
- RE: Shift selection using interactive spec, Drew Adams, 2008/03/17
- Re: Shift selection using interactive spec, Kim F. Storm, 2008/03/18
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/18
- Re: Shift selection using interactive spec, Kim F. Storm, 2008/03/18
- Re: Shift selection using interactive spec, Stefan Monnier, 2008/03/18
- RE: Shift selection using interactive spec, Drew Adams, 2008/03/18
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/20
- Re: Shift selection using interactive spec, Stefan Monnier, 2008/03/22
- Re: Shift selection using interactive spec, martin rudalics, 2008/03/17