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 verify it.
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:
^-S## @HO[DEL][DEL]IN[DEL][DEL]TO[ESC] [...] 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.
Agree :)
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.