On Nov 29, 2004, at 17:45, Josh DiMauro wrote:
[...] you need
to make the process rely as little as possible on
external input (e.g. the need to visually recognize something
throughout the process) and remove as many conscious decisions from
the process as possible (i.e. the need to decide next "action" based
on present non-predictable (by the mind) context).
The problem with your argument
is that the issue here is not whether
the "context" is predictable. There is little difference between the
context of a search dialog box and the floating window of i-search.
I'm referring here to the mental context (i.e. the state of mind) --
when I hit cmd-f, enter "foo (" and press return I know (in my mind)
that "foo (" will be selected in the declaration of the foo function
and I can continue to work from this point w/o having to visually
I.e. I ignore the external context of actually seeing the find window
or verifying that the search went okay -- the action to take after the
search follows naturally and there is no "break", e.g. if I were to
copy the line declaring the prototype I'd do option-l, cmd-c with the
pause between return and ( to start the search, and between return and
option-l probably being very similar.
This of course only when searching is used for navigational purposes --
but this is probably what would make sense to optimize for.
So if the argument were that i-search is faster because I would in this
case only have to type 'fo' to get to where I wanted, this argument is
very much flawed because it looks only at the physical work and not on
the thought process, which is often what slows us down (most of us can
probably type >50 words pr. minute, but we don't, because other things
are slowing us down).
I know this wasn't your argument -- I just wanted to clarify my own,
which was in response to the 'i-search is faster'.
Allow me to give a common example: I have a very large
text file (my
todo.txt list) which has subsections with headers that I often
navigate through. It's just simply faster to hit:
[...] I'm interested in getting to them in the order I think of them.
This is interesting -- I'd argue that you are actually getting new
functionality out of the i-search, because you turn the search string
into a way to move the caret by issuing the proper commands.
And I'd imagine that this process is very much geared toward
automation/no cognitive overhead other than thinking of the actions you
want to perform.
Search as navigation is a function that is poorly
served by the
standard search dialog box.
As to the command key: please, let's keep it ^-s.
I was thinking I'd just name my function the same as the
iSearch-plugin's, so those who have bound keys to this function will
just see it also work in TM.
People who want it on cmd-/ can always change the default bindings.