Hello. New user, here.
I'm loving TextMate so far, although I've only used it for about 12 hours. :) And I googled the mailing list archives for an answer to a question I had, but couldn't find it. Thus, I ask you:
I'm an addicted user of the i-search cocoa plugin, which duplicates Emacs' isearch functionality, with the same keystroke: ^-s forward, ^-r backwards.
http://michael-mccracken.net/blog/blosxom.pl/computers/mac/programming/iSear...
However, I find that this doesn't work inside TextMate, and that makes me sad.
Can you help make me not sad?
Thanks. :)
On Nov 28, 2004, at 23:32, Josh DiMauro wrote:
I'm an addicted user of the i-search cocoa plugin [...] this doesn't work inside TextMate, and that makes me sad.
TextMate isn't using the NSTextView class so unfortunately none of the existing NSTextView extensions work with TextMate.
I have a mental to-do about checking out the i-search plugin, it sounds like it should be easy to replicate, but I have yet to realize the value of incremental searching ;) is the advantage that you (can) write shorter search strings than you'd normally do in a find window?
According to Allan Odgaard:
value of incremental searching ;) is the advantage that you (can) write shorter search strings than you'd normally do in a find window?
No, the fact that the search begin at the first character you type and refines itself when one types more characters. Think "Spotlight" (in Tiger) or the search in Mail.app or iTunes.
On Nov 29, 2004, at 0:27, Ollivier Robert wrote:
value of incremental searching ;) is the advantage that you (can) write shorter search strings than you'd normally do in a find window?
No, the fact that the search begin at the first character you type and refines itself when one types more characters. Think "Spotlight" (in Tiger) or the search in Mail.app or iTunes.
But Mail/iTunes/etc. filter the contents based on the string typed. As I understand it (and currently see the iSearch plugin function) this incremental search selects a single item and does no filtering.
So this is (as I see it) realtime feedback on the string you enter in the find panel (but no new functionality).
With my typing speed I probably have the find panel open for less than a second, so incremental search wouldn't do anything for me, also because I rarely synchronize my "typing" with what's going on on the screen.
That's the reason why I asked if it gave rise to shorter find strings -- I can imagine that with lesser/no knowledge about the text searched and/or a slower typing speed and/or more reliance on the visual feedback given while typing, it could be an advantage to type letter-by-letter until observing that enough had been typed to find the desired string.
But maybe I'm overlooking something -- it would be nice to hear from users of this feature why they see it as an advantage over normal search.
Speaking in general here, I don't mind implementing features that I personally have no use for, but I do want to understand why others have a use for the feature before implementing it! :)
I don't know how iSearch does it, but the way things work in Emacs is that as you type the search string, _all_ matches are highlighted, not just the next one. This would be really useful for when you'd like to click 'replace all', but want to be sure you're not replacing anything you want to be... In the normal Cocoa context, in this situation you pretty much have to command-g your way through the whole document, checking each match one at a time. On the other hand, when all the matches are highlighted at once, you can instantly make sure you're matching exactly what you want to match.
Also, incremental search is useful for debugging regular expressions, because you'll know as you're typing precisely where things went wrong... This could be particularly useful when putting together syntax definitions.
(Speaking of find stuff, it's really great that macros no longer (as of a few betas ago) kill your find string...)
On Nov 28, 2004, at 7:00 PM, Allan Odgaard wrote:
On Nov 29, 2004, at 0:27, Ollivier Robert wrote:
value of incremental searching ;) is the advantage that you (can) write shorter search strings than you'd normally do in a find window?
No, the fact that the search begin at the first character you type and refines itself when one types more characters. Think "Spotlight" (in Tiger) or the search in Mail.app or iTunes.
But Mail/iTunes/etc. filter the contents based on the string typed. As I understand it (and currently see the iSearch plugin function) this incremental search selects a single item and does no filtering.
So this is (as I see it) realtime feedback on the string you enter in the find panel (but no new functionality).
With my typing speed I probably have the find panel open for less than a second, so incremental search wouldn't do anything for me, also because I rarely synchronize my "typing" with what's going on on the screen.
That's the reason why I asked if it gave rise to shorter find strings -- I can imagine that with lesser/no knowledge about the text searched and/or a slower typing speed and/or more reliance on the visual feedback given while typing, it could be an advantage to type letter-by-letter until observing that enough had been typed to find the desired string.
But maybe I'm overlooking something -- it would be nice to hear from users of this feature why they see it as an advantage over normal search.
Speaking in general here, I don't mind implementing features that I personally have no use for, but I do want to understand why others have a use for the feature before implementing it! :)
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
On 28-Nov-04, at 6:00 PM, Allan Odgaard wrote:
But maybe I'm overlooking something -- it would be nice to hear from users of this feature why they see it as an advantage over normal search.
Speaking in general here, I don't mind implementing features that I personally have no use for, but I do want to understand why others have a use for the feature before implementing it! :)
Since this was my number one "missing feature", I think there's three reasons why implementing incremental search is important:
1. It's faster. Yes, maybe you only have the find dialog box open for less than a second, but: "Ctrl-S + Partial search string" is always going to be faster than "Apple-F + Full Search String + Enter". Also launching the dialog box occasionally takes a non trivial amount of time, particularly if the app has been swapped out. Factor in people who type slower, or those people who search out that last little bit of efficiency and it makes a difference.
2. Launching a dialog box is unnecessary for this task -- sometimes the dialog box obscures text that I am using for reference.
3. Many apps are moving towards this style, and people may be used to this way of working. As an emacs user, the incremental search style of working was ingrained into my usage patterns, and when beginning to use TextMate I was regularly frustrated with its absence. In addition to emacs -- this style of search is now becoming default in apps, so more people may become used to this ability -- the isearch plugin for NSTextView, Firefox, iTunes, etc. Better to give those addicted to isearch their fix, rather than have them look elsewhere, right?
That all said, I've largely gotten used to working without it. Indeed other features of TextMate such as making use of code folding has replaced my constant use of isearch for jumping around within a file. But I still look forward to the day it gets added to TextMate!
Wayne
On Nov 28, 2004, at 7:05 PM, Wayne Larsen wrote:
- It's faster. Yes, maybe you only have the find dialog box open for
less than a second, but: "Ctrl-S + Partial search string" is always going to be faster than "Apple-F + Full Search String + Enter". Also launching the dialog box occasionally takes a non trivial amount of time, particularly if the app has been swapped out. Factor in people who type slower, or those people who search out that last little bit of efficiency and it makes a difference.
Yes, it is much faster.
- Launching a dialog box is unnecessary for this task -- sometimes
the dialog box obscures text that I am using for reference.
The above is why it is much faster. I cringe when forced to use a dialog box for all searching. Being an emacs user and a firefox user, these are key productivity boost when navigating some form of a text document.
- Many apps are moving towards this style, and people may be used to
this way of working. As an emacs user, the incremental search style of working was ingrained into my usage patterns, and when beginning to use TextMate I was regularly frustrated with its absence. In addition to emacs -- this style of search is now becoming default in apps, so more people may become used to this ability -- the isearch plugin for NSTextView, Firefox, iTunes, etc. Better to give those addicted to isearch their fix, rather than have them look elsewhere, right?
That all said, I've largely gotten used to working without it. Indeed other features of TextMate such as making use of code folding has replaced my constant use of isearch for jumping around within a file. But I still look forward to the day it gets added to TextMate!
Wayne
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
On 29. nov 2004, at 5:14, Wileks Joiner wrote:
On Nov 28, 2004, at 7:05 PM, Wayne Larsen wrote:
- It's faster. Yes, maybe you only have the find dialog box open
for less than a second, but: "Ctrl-S + Partial search string" is always going to be faster than "Apple-F + Full Search String + Enter". Also launching the dialog box occasionally takes a non trivial amount of time, particularly if the app has been swapped out. Factor in people who type slower, or those people who search out that last little bit of efficiency and it makes a difference.
Yes, it is much faster.
How about some more concrete reasons? I count (apart from partial vs. full) three things in the first part: Apple-F, enter string, Enter. In the second there is two, but surely you need to press some key to go back to normal editing, be it arrow escape of enter. So that makes.. three also. Contrast that to "much faster". I mean.. I like incremental search too, and sometimes it is a bit faster and more convenient since it highlights all matches but still ;-).
- Launching a dialog box is unnecessary for this task -- sometimes
the dialog box obscures text that I am using for reference.
The above is why it is much faster. I cringe when forced to use a dialog box for all searching. Being an emacs user and a firefox user, these are key productivity boost when navigating some form of a text document.
Aha, but for i-search where would you enter your search string? You still have to enter it somewhere, so if it launches a dialog or moves input to a pop-up string gadget or whatever, where is the enormous speed difference?
[...] this style of search is now becoming default in apps [...] the isearch plugin for NSTextView, Firefox, iTunes, etc.
Hmm... because of a 3rd party plugin? Hardly the same as being default in the app ;-).
On 29.11.2004, at 13:35, Sune Foldager wrote:
Aha, but for i-search where would you enter your search string? You still have to enter it somewhere, so if it launches a dialog or moves input to a pop-up string gadget or whatever, where is the enormous speed difference?
Dunno about i-search, but in emacs and Firefox this happens in the status bar (extension in the latter). This has the obvious advantage of not jumping on top of your valuable text. The focus is always on the first matching text (other matches are highlighted with a slightly different color) and you don't have to fiddle around with the open find window.
On 29.11.2004, at 13:12, Allan Odgaard wrote:
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).
It is (see the prev paragraph).
And yes, let's use ctrl-s for launching incremental search when it is implemented in TextMate.
//jarkko
-- Jarkko Laine http://jlaine.net
On Nov 28, 2004, at 11:14 PM, Wileks Joiner wrote:
The above is why it is much faster. I cringe when forced to use a dialog box for all searching. Being an emacs user and a firefox user, these are key productivity boost when navigating some form of a text document.
I'm a longtime Emacs user. I've been using OS X for more than a year and TM is what it took for me to ditch the (horribly buggy and crash-prone) Emacs build for OS X. I've had a lot of muscle memory to un-learn but I do like TM. Hey, I paid for it, which is saying a lot for me!
Someone mentioned emacs highlighting every search; for me, this is not a huge deal. What's most important is jumping to the point in the document after the cursor where the search first hits, and updating itself as the search phrase is expanded.
I eschew Firefox on OS X because its interface is *very* "un-Mac", but I really dig the search thingy that pops up at the bottom of the window when you type "/whatever". That would be a really nifty add'n to TM. But just being able to type "^swhatever^s^s" to jump to the third match for "whatever" in my current document would may me just jibber with happiness. :-)
On Mon, 29 Nov 2004 01:00:00 +0100, Allan Odgaard allan@macromates.com wrote:
But Mail/iTunes/etc. filter the contents based on the string typed. As I understand it (and currently see the iSearch plugin function) this incremental search selects a single item and does no filtering.
Filtering makes more sense in a "browser" function such as Spotlight, IMO. In an editor, filtering may cause trouble, by removing necessary context. Consider the annoyance of searching for a "<h3>links</h3>" header, and not being able to see what links follow it, which would be the information you need to know what particular header you wanted.
(yeah, yeah. Comment your code. Pretend you're editing someone else's sloppy code, then. :))
So this is (as I see it) realtime feedback on the string you enter in the find panel (but no new functionality).
No new functionality beyond the realtime feedback itself, but the realtime feedback is itself important. :)
With my typing speed I probably have the find panel open for less than a second, so incremental search wouldn't do anything for me
I type quickly, as well. However, the difference between opening a dialog box and incremental search is one of not having to shift the locus of my attention. The locus of my attention, in a text editor, should be at "point" (to use an emacsism). I don't fault you for not being distracted by the Find dialog box, but for myself (and others, I suspect) it is an issue.
That's the reason why I asked if it gave rise to shorter find strings -- I can imagine that with lesser/no knowledge about the text searched and/or a slower typing speed and/or more reliance on the visual feedback given while typing, it could be an advantage to type letter-by-letter until observing that enough had been typed to find the desired string.
That's pretty much it... but the advantage is less the shorter find string, and more the ability to fine tune by either narrowing or widening the search with a couple keystrokes, without having to reopen a dialog box. The difference is subtle, but (I feel) important.
Speaking in general here, I don't mind implementing features that I personally have no use for, but I do want to understand why others have a use for the feature before implementing it! :)
Quite understandable. :)
Incremental search seems to be one of those things that makes a subtle difference in reducing resistance to use. It's not so much that I need it to do all my searching. It's more that, when I don't have it available, I search less, and that makes me less efficient.
-
Allan Odgaard -
Brian Lalor -
Jarkko Laine -
Josh DiMauro -
Ollivier Robert -
otheraccount＠verizon.net -
Sune Foldager -
Wayne Larsen -
Wileks Joiner