Makes sense, although I can't speak to how the implementation could change to accommodate this, I think as a usability issue perhaps a workaround is to detect when there is super long line in the file, and if so and user has soft wrap turned on, prompt user to disable that for this particular file. This is especially a good thing to do with state restoration, because once user accidentally opens such a file, TM will keep trying to open it on subsequent launch.
On Sat, Dec 7, 2013 at 5:44 PM, Allan Odgaard mailinglist@textmate.orgwrote:
On 8 Dec 2013, at 3:30, Walter Lee Davis wrote:
FWIW, I believe this happens because of the regular expression scanning
going on to effect syntax highlighting. If you can set this particular file type to .txt or another non-highlighted format first, you may find that opening it goes faster.
I believe the main issue is text layout. This is pretty expensive and it’s hard to break up a single line partly due to unicode rules partly because we need the width of the full line (which requires the full line to go through layout).
Enabling soft wrap should improve performance significantly since here we do break up the line (on spaces) and only the stuff that is visible will actually go through layout, so smaller chunks are given to CoreText.
It’s a known issue, but how to fix it is challenging, as effectively we need to pass less to CoreText, and to do that properly we need to partially replicate unicode rules in TextMate (instead of leaving that to the system) and also need to estimate glyph widths to have some estimates to use before we get real values from CoreText.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate