[TxMt] Arrow behavior with selected text--bug?
Dr. Drang
drdrang at gmail.com
Wed Mar 8 05:56:51 UTC 2006
On 3/7/06, Allan Odgaard <throw-away-1 at macromates.com> wrote:
> On 8/3/2006, at 0:17, Dr. Drang wrote:
>
> > So, unless I've inadvertently changed some setting to start this
> > behavior, I would call this a bug.
>
> It's by design, I may change it -- there should be lots of mentions
> of this in the archive.
Well, I hope the acrimonious discussion of this issue last November
has not turned you deaf to my pleas. There are, I think, three very
good reasons to change the current behavior:
1. History/conformity. Mr. Van Ittersum (the user whose complaint
started the thread in November) was right when he said that TM's
behavior with regard to double-clicking and arrowing is unlike every
other Mac program currently or in the past. As I said in my first
message, I started using Macs in 1985, and I have never run into this
behavior before. I'm pretty sure Windows editors don't behave this
way, and I know that the wonderful Motif editor NEdit (which you
admire, too) doesn't. And while "everyone else does it" is not an
argument that should trump all other concerns, it does mean that your
user base has certain expectations, and confounding those expectations
should be done only if there is a significant gain. The one advantage
you mentioned in the November thread--the ability to use an arrow key
as an "undo" for a mistaken Command-A--has really no bearing on what
the arrow keys do after a double-click word selection.
2. Double-clicking on a word has nothing to do with any individual
character in that word. This, I think, is the main problem I have with
the current behavior. When I double-click on a word to select it, the
character that I happen to double-click on is of no consequence to me;
it doesn't even enter my mind. I'm thinking of that word as a single
entity. I may delete it, I may overwrite it, I may--and this is where
I ran afoul of the current behavior--call a command or macro to act on
it. But I am certainly not thinking about, or even aware of, the point
within the word where I first clicked.
The user interface encourages this way of thinking by eliminating the
blinking cursor while the selection is active. This is a visual
indication that the caret is to be thought of as smeared over the
entire selection.
3. The behavior is not consistent with the way arrow keys work when a
selection has been made another way. When a selection is made by
dragging through text a right arrowkey press puts the caret at the end
of the selection and a left arrowkey press puts the caret at the
beginning of the selection--regardless of whether the drag was done
from left to right or right to left. The same is true when a selection
is made by shift-clicking. As far as I know, the arrow key behavior is
the only behavior that cares how a selection was made.
--
Dr. Drang
More information about the textmate
mailing list