On 27/5/2006, at 16:03, Aristide Grange wrote:
Thank you for having explained me how to solve this stupid-but-big problem with search/replace in TextMate! [...]
Just FYI the problem comes not from stupid code but from data structure trade-offs.
Thank you for your very interesting explanations about the data structure you use. My intervention on the topic was initially motivated by the fact that Chris mentioned the same (stupid) problem on a 3.7MB XML file:
The big mistake was to try and do a Find/Replace of all ">" with "> \n". Whoah. It's been using all the CPU and beachballing for over 30 minutes now, with no obvious way to interrupt it...
From my point of view, the problem of Chris was including two independant matters: 1. slow global replacement; 2. global reparsing. I was surprised that your reply to him (well, the kind one) focused almost only on parser considerations. It was not perfectly clear for me that your promise of future improvements on "half a dozen other things which do affect the performance" included the one I care about. So, I thought it was necessary to insulate the first problem, with which I have to deal on a daily basis: global replacement on plain text. Obviously, I knew it had "nothing to do with the language parser": it was precisely my point...
Then, Paul came with a great solution to this very problem: filter the document through a magic perl command. Since them, I am happy, and I guess TextWrangler will not encuber my dock for a long time now. But his reply makes a second (probably stupid too) question to pop into my mind: since there is such a performance issue with the builtin global replacement of TextMate, why not just delegate the work to perl, directly from the shiny and so convenient Find window? And if, for some reason, it is not always possible, why not offer this as an option through some cute check box?
Concerning the "marketing" considerations of Daniel, I second that. My own experience, as an old BB et al. registered user, is the following: in the past, I have given TextMate at least three (too) short tries. Each time, I thought: "it is not for me, because 1. there is no incremental search; 2. global replacement is too slow". The drawback with TextMate is that its real superiority and its amazing features are not very prominent. This "tact" has several very important advantages too, e.g., the interface is not bloated and the learning curve is so smooth. But I have had to force me to try TextMate during one plain week *before* I finally fall in love with it. BTW, I don't remember if I registered before or after I accidentally discovered it does offer incremental search (the manual is rather allusive on this point). So I think it would be a killer marketing idea to help the switchers to figure out how they can use TextMate as efficiently as their favourite text editor. Apple has made something like that for the Windows users (and we all know that Apple never makes any marketing error ;-). Perharps some dedicated annex in the documentation?
Cheers,
A.
On a slightly less theoretical note - I have added ctrl-option-cmd-s to the Experimental bundle as "Strip Matching Lines" to make working around this easier. It can easily be modified (or possible extended) to do arbitrary replacement as well.
-David
Aristide Grange wrote:
On 27/5/2006, at 16:03, Aristide Grange wrote:
Thank you for having explained me how to solve this stupid-but-big problem with search/replace in TextMate! [...]
Just FYI the problem comes not from stupid code but from data structure trade-offs.
Thank you for your very interesting explanations about the data structure you use. My intervention on the topic was initially motivated by the fact that Chris mentioned the same (stupid) problem on a 3.7MB XML file:
The big mistake was to try and do a Find/Replace of all ">" with ">\n". Whoah. It's been using all the CPU and beachballing for over 30 minutes now, with no obvious way to interrupt it...
From my point of view, the problem of Chris was including two independant matters: 1. slow global replacement; 2. global reparsing. I was surprised that your reply to him (well, the kind one) focused almost only on parser considerations. It was not perfectly clear for me that your promise of future improvements on "half a dozen other things which do affect the performance" included the one I care about. So, I thought it was necessary to insulate the first problem, with which I have to deal on a daily basis: global replacement on plain text. Obviously, I knew it had "nothing to do with the language parser": it was precisely my point...
Then, Paul came with a great solution to this very problem: filter the document through a magic perl command. Since them, I am happy, and I guess TextWrangler will not encuber my dock for a long time now. But his reply makes a second (probably stupid too) question to pop into my mind: since there is such a performance issue with the builtin global replacement of TextMate, why not just delegate the work to perl, directly from the shiny and so convenient Find window? And if, for some reason, it is not always possible, why not offer this as an option through some cute check box?
Concerning the "marketing" considerations of Daniel, I second that. My own experience, as an old BB et al. registered user, is the following: in the past, I have given TextMate at least three (too) short tries. Each time, I thought: "it is not for me, because 1. there is no incremental search; 2. global replacement is too slow". The drawback with TextMate is that its real superiority and its amazing features are not very prominent. This "tact" has several very important advantages too, e.g., the interface is not bloated and the learning curve is so smooth. But I have had to force me to try TextMate during one plain week *before* I finally fall in love with it. BTW, I don't remember if I registered before or after I accidentally discovered it does offer incremental search (the manual is rather allusive on this point). So I think it would be a killer marketing idea to help the switchers to figure out how they can use TextMate as efficiently as their favourite text editor. Apple has made something like that for the Windows users (and we all know that Apple never makes any marketing error ;-). Perharps some dedicated annex in the documentation?
Cheers,
A.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-
Aristide Grange -
David Powers