[TxMt] i-search in TextMate

[Allan Odgaard]

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.