[TxMt] i-search in TextMate

[Allan Odgaard]

On Nov 29, 2004, at 2:05, Wayne Larsen wrote:
> [...] "Ctrl-S + Partial search string" is always going to be faster 
> than "Apple-F + Full Search String + Enter" [...]

On Nov 29, 2004, at 5:51, Carl Forde wrote:
> [...] cmd-f and filling in a dialog box is requires much more 
> cognitive effort because of the two context switches required

While I have yet to try out i-search, I do think you guys are wrong. To 
maximize your workflow 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).

While with enough use I imagine you'll condition yourself to 
incorporate the visual feedback from the i-search into the decision 
process (as in associative learning), and less conscious thought will 
be required -- personally though, I generally do not realize I've 
miscalculated something before a few actions after the point of 
disagreement between my mental model and the real world, meaning that 
any process where visual feedback is optional, I'll perform faster w/o 
the visual feedback, often even if it requires more physical work (as 
in typing the full function name followed by " (" to find the 
declaration of a function, rather than iterative typing and visually 
monitoring when I've actually found the function).

I think the Firefox example as supportive evidence of the usefulness of 
this kind of search in a text editor is wrong for a few reasons:

  1) searching in a browser is generally trying to obtain information 
not easily available, so the task at hand is to find new information, 
so (mental) automation is not even on the table -- in a text editor 
OTOH we may often use search simply as a navigation aid, and thus some 
degree of automation is possible and IMHO very much desired.

  2) the text in a browser is generally unknown and thus unambiguous 
search strings are not easily created. If you'd written all the text 
yourself this would be easier and you may even have a system to 
disambiguate different elements of the text (e.g. a function call from 
a function prototype/declaration).

  3) as I understand it, Firefox highlights all matches in one go, 
adding new functionality -- the iSearch plugin doesn't, but I 
understood another letter as saying Emacs does do this!?! then however 
I'm not sure how to proceed after the i-search (if the search hasn't 
been narrowed down to a single match).

All this said, I do intend to implement the i-search functionality, if 
for no other reason than to (dis)verify my own belief ;)

My argument is btw not that standard search is faster than i-search, 
only that given the right circumstances (i.e. a user who can blind 
type, is inclined to associative learning and having a workflow that 
relies little on decision making (as navigating in structured text 
shouldn't do)), the i-search is not going to be faster, and I'd even 
say it caters to the wrong (if the goal is automation) type of implicit 
learning.

A thing to remember is that each time an automated action is repeated, 
the person becomes faster at doing this action (there's a logarithmic 
speedup over time) -- so if we have two methods to achieve the same 
goal and only one caters for automation, then even if this is initially 
the slower way of doing things, it may over time be the faster one.