Is it just me or tab switching is really slow on b17? Switching either by clicking or using keyboard shortcuts is taking up to 2s here.
If it's of any help: I'm working on a rails project (so, mainly small ruby files), less than 6 tabs open generally, and using the pastels on dark theme. There's plenty of free RAM, and I'm on Panther.
On 04/09/2005, at 8.59, Caio Chassot wrote:
Is it just me or tab switching is really slow on b17? Switching either by clicking or using keyboard shortcuts is taking up to 2s here.
It's likely to have become slower than b16, because of the new (ANTLR generated) scope parser.
I can however cache the result from running the parser, which should bring it back to at least b16 speed.
Just for testing, could you try switching to Plain text and see if tab-switching is faster for that (that'd be when switching to a plain text file)?
Just for testing, could you try switching to Plain text and see if tab-switching is faster for that (that'd be when switching to a plain text file)?
Yes, much faster.
Another suggestion, maybe you could withhold rendering of the document for a short while, so if a press Cmd+Opt+arrow repeated times to jump to a distant tab, it doesn't waste time rendering every tab inbetween. (I'm aware of the cmd+number shortcuts, can't get used to it though)
On 04/09/2005, at 9.33, Caio Chassot wrote:
Another suggestion, maybe you could withhold rendering of the document for a short while, so if a press Cmd+Opt+arrow repeated times to jump to a distant tab, it doesn't waste time rendering every tab inbetween.
Then, that would suck if you just want to go to the next tab, which is what I usually do since I arrange the most used ones next to eachother :-P. Alternatively, abort rendering on receiving the next key event, but this, I fear, requires more drastic changes to the internals.
-- Sune.
On Sep 04, 2005, at 09:38, Sune Foldager wrote:
On 04/09/2005, at 9.33, Caio Chassot wrote:
Another suggestion, maybe you could withhold rendering of the document for a short while, so if a press Cmd+Opt+arrow repeated times to jump to a distant tab, it doesn't waste time rendering every tab inbetween.
Then, that would suck if you just want to go to the next tab, which is what I usually do since I arrange the most used ones next to eachother :-P. Alternatively, abort rendering on receiving the next key event, but this, I fear, requires more drastic changes to the internals.
Do keep in mind that I mean withholding rendering for no longer than 200ms. It could always be a hidden pref anyway :)
Aborting is indeed a better idea, but as you noted, probably harder to implement.
On 04/09/2005, at 16.48, Caio Chassot wrote:
Do keep in mind that I mean withholding rendering for no longer than 200ms. It could always be a hidden pref anyway :)
I like the idea with the delay, and it's what the system does for keyboard controlled tabs (iirc), OTOH it may also just add further delay when one wants to move only a single tab.
Though for tab switching being slow in b17, try this version (where I cache the result from the scope selector parser, so it should no longer be the bottleneck): http://macromates.com/textmate/files/ TextMate_1.1b17_2005-09-05.zip
Though for tab switching being slow in b17, try this version (where I cache the result from the scope selector parser, so it should no longer be the bottleneck): http://macromates.com/textmate/files/TextMate_1.1b17_2005-09-05.zip
I installed it over the previous b17 and it seems to have lost all language definitions.
Do I have to svn co them or something? If so please tell me the url and where to check it out to. (I jumped from b5 to b16 and never really dealt with this situation)
On 06/09/2005, at 0.25, Caio Chassot wrote:
I installed it over the previous b17 and it seems to have lost all language definitions.
Yeah, sorry, it didn't include any bundles.
Do I have to svn co them or something?
You can re-download this version instead: http://macromates.com/textmate/build/TextMate_r369.zip
I have now setup an RSS feed [1] with change log. The actual entry link points to the build, which does contain bundles, but currently is only a PPC build (I may look into RSS enclosures instead).
Kind regards Allan
You can re-download this version instead: http://macromates.com/textmate/build/TextMate_r369.zip
Ok, tested tab switching with this one. It's not super mega fast, but it's much better already. And... cmd+opt+. is working.
On 5 Sep 2005, at 20:13, Allan Odgaard wrote:
I like the idea with the delay, and it's what the system does for keyboard controlled tabs (iirc),
If you do lazy font locking, it's also how (x)emacs does it. I don't know the details, but I think it works by only fully parsing and rendering the visible part of the page, pushing the rest back into a hook in the idle loop. I guess at least you could only process the file up until the point where it's no longer visible (I don't see how to get the full context, if you don't always begin at the top of the file, but perhaps that's not actually necessary) and push the rest of the parse out to an idle loop? Or something entirely unlike that? :)
OTOH it may also just add further delay when one wants to move only a single tab.
Which is probably the most common use case? Certainly for those of us who rearrange the tabs to make that the most common use case. :)
Which is probably the most common use case? Certainly for those of us who rearrange the tabs to make that the most common use case. :)
I suppose I have to jump in here and add to the statistics by saying that I often skip more than one tab, actually, I usually use command +t because I have so many tabs open. I move to different "areas" of the project all the time, which means different buffers open, and I wouldn't want to rearrange tabs all the time.
Andreas
Furthermore, I think we should have spatial buffers