Hi,
I'm on 10.6.8, 2.93Ghz Core2Duo, 4Go ram
All the file i open take time to be parse for syntax coloration, and if i open like 10 file it take more than 2sec to open or switch to a previous open file. Also to close a file. Like this TM2 is just not usable.
All working fine with TM1 with the same project.
Also the bundle PHP Cake doesn't work when i check the scope text.html.php.cake as not present.
Thanks, Mickael
On Dec 16, 2011, at 11:36 , ExploZe wrote:
Hi,
I'm on 10.6.8, 2.93Ghz Core2Duo, 4Go ram
All the file i open take time to be parse for syntax coloration, and if i open like 10 file it take more than 2sec to open or switch to a previous open file. Also to close a file. Like this TM2 is just not usable.
All working fine with TM1 with the same project.
Do a backup of custom bundles, completely remove all tm1 prefs and files (using tools like appremover or amnesia or forklift) Worked for me when had this issue. After cleanup (probably incompatibility of some tm1 pref) it's working like a charm (almost)
best
I'm having this problem too. Every time I open a new file or begin typing in an unmodified buffer, TextMate hangs for a good 5 seconds. I tried deleting ~/Library/Application Support/TextMate, ~/Library/Preferences/com.macromates.*, and anything else I could find, but that didn't help.
The behavior seems to be bundle-specific. Java and XML files hang; Objective-C files do not.
Trevor
On Dec 16, 2011, at 4:09 AM, Daniel Dettlaff wrote:
On Dec 16, 2011, at 11:36 , ExploZe wrote:
Hi,
I'm on 10.6.8, 2.93Ghz Core2Duo, 4Go ram
All the file i open take time to be parse for syntax coloration, and if i open like 10 file it take more than 2sec to open or switch to a previous open file. Also to close a file. Like this TM2 is just not usable.
All working fine with TM1 with the same project.
Do a backup of custom bundles, completely remove all tm1 prefs and files (using tools like appremover or amnesia or forklift) Worked for me when had this issue. After cleanup (probably incompatibility of some tm1 pref) it's working like a charm (almost)
best _______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 16 Dec 2011, at 18:34, Trevor Harmon wrote:
Every time I open a new file or begin typing in an unmodified buffer, TextMate hangs for a good 5 seconds. […]
Try relaunch TextMate and hold ⇧ so you get no session restore.
Open a file without ever bringing up the file browser.
See if the performance is still bad.
If not, this most likely is related to SCM status updating done by the file browser.
The file browser has an intermitten problem with mercurial (hg) repositories.
Some users initialize their home folder as a mercurial repository and that’s presently a recipe for disaster with the current file browser since any file system change under ~ will cause it to ask for updated SCM status and any folder shown by the browser will be marked as part of this huge repostiroy rooted at ~.
On Dec 18, 2011, at 2:24 AM, Allan Odgaard wrote:
On 16 Dec 2011, at 18:34, Trevor Harmon wrote:
Every time I open a new file or begin typing in an unmodified buffer, TextMate hangs for a good 5 seconds. […]
Try relaunch TextMate and hold ⇧ so you get no session restore.
Open a file without ever bringing up the file browser.
See if the performance is still bad.
If not, this most likely is related to SCM status updating done by the file browser.
I did some more experiments and it is not an SCM issue. If I make a duplicate of the directory with no trace of Git (using "git archive"), I can still get the extreme slowness. Also, a different project that uses Git doesn't have the problem.
It has something to do with how deep the file browser hierarchy is. For example, if I open my entire project in TextMate, the slowness is there, but if I open a subdirectory of the project with only a few files in it, the problem goes away. Interestingly, the height of the subdirectory in the hierarchy seems to correspond to the slowness. For example, if there's a directory in the project foo/bar/baz, then opening foo = slow, bar = a little bit faster, baz = faster still, etc.
However, I also have a project of about the same size, also managed by Git, and I can't reproduce the problem there at all. It is almost entirely Objective-C files, whereas the problematic project is almost all Java and XML files, so I still think the bundle/grammar is a factor here.
Trevor