[TxMt] Performance issues

[Aristide Grange]

> 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.