Open file with one line type very slow

[ghost]

If I open a file with one line type, example a foundation.min.css file (It has 160KB size but one line script) It's very slow, and this happen when I try 'find', 'replace', and editing the file.

Then when I try to find a word and that found , the 'yellow highlight' in right scrollbar is shown on top, which the founded words is on middle of scrollbar (Maybe its something bugs, cause Its the one line type file, then the 'yellow highlight' shown on line 1)

[redmunds]

@engkusk This is a known issue. Do you really edit minified css files? Generally, searching, debugging, and editing of css is done in original file, then the minified css is re-generated when you're done.

[petetnt]

There should be an escape hatch of some sort (either for the code or the user) to bail out from these kinds of situations. It's rather grating when you accidentally open up a minified file / similar and all you can do is see whether Brackets recovers or just do a hard reboot.

[marcelgerber]

@engkusk The second issue you mentioned, with the scroll track markers all in one place, will be fixed in the next version of Brackets.

@petetnt We (and CodeMirror) already have some safeguards in place so we don't do too much work, so I think a big part of this is also time spent in extension code. But I just ran a timeline recording while opening jquery-2.1.3.min.js and as it turns out, most of the time is spent in layouting calls caused by forced reflow through CM (10 calls, each taking >800ms).

I'm not sure what we, or even Marijn, can do about it. I don't think it's possible to defer all these calls to the end.

[marcelgerber]

Okay, it turns out that most of these layout calls are probably still our fault, as the vanilla CM demo can handle the same content with just two layout calls. Sure, there might be some configuration differences that make up for some of that, but 2 calls vs 10 is still a pretty big discrepancy.