[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: |
Sun, 16 Mar 2008 14:40:26 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
> That's a problem because the current mark in Emacs doesn't
> traditionally behave anything like the beginning of a "shift-selected"
> region. It's a force fit, at best. The addition (by transient-mark-mode)
> of an "activated/de-activated" flag is a crude *approximation*
> of what users expect, in a situation where no approximating is
> necessary. For example, a "right arrow" key-press should simply
> *forget*, more or less entirely, the marker at the start of the
> highlighted region. That's the default behavior if tentative mark
> functionality is added but it's functionality that would require
> yet more elisp code if transient-mark-mode were to catch up with
> it.
I do not follow you, Tom: how would the right arrow magically forget
your tentative mark? In what way is that different from setting
mark-active to nil? I have the strong impression that you do not know
what is the "temporary" form of transient-mark-mode" (this is
a transient-mark-mode that's activated until the region is "consumed")
and neither do you know about the "only" form of transient-mark-mode
(that is a form of transient-mark-mode which is deactivated after the
very next command).
> What users expect, in the traditional GUI paradigm, is a kind of
> mark that doesn't toggle between "activated" and "deactivated" but,
> rather, is always active when present but which commands tend to
> cause to go away entirely. Let's dub that "the mistake". The
> mistake is adding an "active" flag instead of a separate tentative
> mark.
In what way is it different, really? The problem is how/when to
activate/set it and how/when to deactivate/unset it. Whether it's
a flag or a mark makes no difference.
> It's *because* of the mistake that, for example, Stefan is now
> positing the existence of a formal category of "motion commands"
> that have to be modified to call a function that dynamically
> asserts that they are motion commands.
??? The notion of "motion commands" is needed because the behavior we
want is "when a motion command is bound to a non-shifted key but is
activated via the shifted of that key, we want the motion to select
a region".
Try it in your typical GUI editor: S-arrow will select a region, but S-a
will just insert an upper-case A.
I.e. this need is 100% unrelated to the way the selected region is
implemented and when/how it gets de-selected.
Stefan
- Re: Shift selection using interactive spec, (continued)
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/15
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/15
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/15
- Re: Shift selection using interactive spec, Mathias Dahl, 2008/03/16
- Re: Shift selection using interactive spec, Chong Yidong, 2008/03/16
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/16
- Dear lazyweb (Re: Shift selection using interactive spec), Thomas Lord, 2008/03/16
- Re: Shift selection using interactive spec,
Stefan Monnier <=
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/16
- Re: Shift selection using interactive spec, Thien-Thi Nguyen, 2008/03/16
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/16
- Re: Shift selection using interactive spec, Thien-Thi Nguyen, 2008/03/16
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/16
- Re: Shift selection using interactive spec, Lennart Borgman (gmail), 2008/03/16
- Re: Shift selection using interactive spec, Lennart Borgman (gmail), 2008/03/16
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/16
- Re: Shift selection using interactive spec, Lennart Borgman (gmail), 2008/03/16
- Re: Shift selection using interactive spec, Thomas Lord, 2008/03/16