Sorry I forgot to mention that i-search requires two new key binding entries which you'll need to manually add if you made a local copy:
"^s" = "ISIM_incrementalSearch:"; "^S" = "ISIM_reverseIncrementalSearch:";
I named my methods the same as the ISearch InputManager/Plugin. So if you already have this installed, the key bindings from your "global" key bindings file should already make it work, _except_ that ISIM use control-r for the reverse search, TextMate is using that for 'execute line', which is why I choose control-S.
Maybe this is why reverse search doesn't work for you Wayne?
Regarding aborting the search with movement keys, that would pretty much make it impossible to go back and make edits in the search string (other than backspace), but maybe no-one does that?
On 1-Dec-04, at 8:53 AM, Allan Odgaard wrote:
Maybe this is why reverse search doesn't work for you Wayne?
That did it, thanks!
Regarding aborting the search with movement keys, that would pretty much make it impossible to go back and make edits in the search string (other than backspace), but maybe no-one does that?
Line up/down would not cause any limitations. You're right though that character forward/back would prevent the edits to the search string. It is a tradeoff -- I see the value of canceling the search with those keys being better than the ability to edit the search string with them. My argument pretty much comes down to "That's how emacs does it" though. :)
Cheers, Wayne
Thanks for adding the feature!
I would like to see any movement key (except backspace) get me out of incremental search.
I don't think it makes sense to edit the search string that you have written incrementally. If I make a mistake in incremental search it is usually apparent after the first wrong character I type.
Thanks,
Brad
On Dec 1, 2004, at 9:32 AM, Wayne Larsen wrote:
On 1-Dec-04, at 8:53 AM, Allan Odgaard wrote:
Maybe this is why reverse search doesn't work for you Wayne?
That did it, thanks!
Regarding aborting the search with movement keys, that would pretty much make it impossible to go back and make edits in the search string (other than backspace), but maybe no-one does that?
Line up/down would not cause any limitations. You're right though that character forward/back would prevent the edits to the search string. It is a tradeoff -- I see the value of canceling the search with those keys being better than the ability to edit the search string with them. My argument pretty much comes down to "That's how emacs does it" though. :)
Cheers, Wayne
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
Brad Miller, Ph.D. Assistant Professor, Computer Science Luther College http://www.cs.luther.edu/~bmiller
Thanks for adding the feature!
I would like to see any movement key (except backspace) get me out of incremental search.
I don't think it makes sense to edit the search string that you have written incrementally. If I make a mistake in incremental search it is usually apparent after the first wrong character I type.
Thanks,
Brad
On Dec 1, 2004, at 8:53 AM, Allan Odgaard wrote:
Sorry I forgot to mention that i-search requires two new key binding entries which you'll need to manually add if you made a local copy:
"^s" = "ISIM_incrementalSearch:"; "^S" = "ISIM_reverseIncrementalSearch:";I named my methods the same as the ISearch InputManager/Plugin. So if you already have this installed, the key bindings from your "global" key bindings file should already make it work, _except_ that ISIM use control-r for the reverse search, TextMate is using that for 'execute line', which is why I choose control-S.
Maybe this is why reverse search doesn't work for you Wayne?
Regarding aborting the search with movement keys, that would pretty much make it impossible to go back and make edits in the search string (other than backspace), but maybe no-one does that?
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
Brad Miller, Ph.D. Assistant Professor, Computer Science Luther College http://www.cs.luther.edu/~bmiller
On Dec 1, 2004, at 9:53 AM, Allan Odgaard wrote:
Regarding aborting the search with movement keys, that would pretty much make it impossible to go back and make edits in the search string (other than backspace), but maybe no-one does that?
I just use backspace to edit the i-search.
On 1.12.2004, at 18:54, Brian Lalor wrote:
On Dec 1, 2004, at 9:53 AM, Allan Odgaard wrote:
Regarding aborting the search with movement keys, that would pretty much make it impossible to go back and make edits in the search string (other than backspace), but maybe no-one does that?
I just use backspace to edit the i-search.
Me too.
-- Jarkko Laine http://jlaine.net
Allan Odgaard wrote:
Regarding aborting the search with movement keys, that would pretty much make it impossible to go back and make edits in the search string (other than backspace), but maybe no-one does that?
Not sure if this is doable (or even sensible, useful), but maybe make it so that if the cursor keys are hit, they walk through the search string -> if that is possible, else, search is aborted. So if you're at the end of the search string and you hit arrow-right it aborts, but if you hit arrow-left it moves the cursor left in the search string and lets you edit. So basically if you hit an arrow key which will not make the cursor move within the search string it aborts. Not sure what the up/down keys should do though..
Regards,
Martin
So basically if you hit an arrow key which will not make the cursor move within the search string it aborts.
IMHO this is a mode, eg the meaning of the arrow key will change whether the cursor is in the search string or at an end. Moreover the user focus is on the occurences hilighted in the file, rather than on the field at the bottom of the window. Since that occurence is selected, it seems coherent that the arrow keys would do what they usually do: exit the selection. Also that behavior will be familiar to Emacs users.
Fixing using backspace shouldn't be so much of a hassle since search strings are typically short, and as the results are incrementally displayed, the user can detect errors early.
-- D
-
Allan Odgaard -
Brad Miller -
Brad Miller -
Brian Lalor -
Damien Pollet -
Jarkko Laine -
M Spreij -
Wayne Larsen