Files with large extremely long lines cause hangs #979
Comments
|
This should be fixed in the v32 release now that #1001 is merged. |
|
Ran in to it freezing upon trying to open |
|
Can you tell me the sha you see under the Atom menu (like in the picture above) |
|
Yup! 4132cdd |
|
(I rebuilt and tried it again in case I missed a commit, thus the really new sha) |
|
@bnferguson Is this freezing when you open |
|
Yup! Still an issue. Just had it lock up in a fresh master build. Downloading screen hero. Later this afternoon or sometime next week should work fine for me. |
|
Another report via support/612cacb6b6fa11e384554e10b2ee9be5
|
|
via support/90240870c84811e39e74c419500d2fe2
I just tried playing with minified jQuery and this is the behavior I observed:
|
|
This issue still exists in 0.100.0. I'm getting a hang on a minified CSS file that consists of only one line with over 237,000 characters. |
|
Same here. I had the issue when editing CSS attributes that had a data encoded image in them. Very long lines. Removing them put everything back to normal. |
|
How does Atom handle files? Is it an array of strings, a buffer, or something else? |
An array of strings, one for each line in the file. |
|
@kevinsawicki does that offer any benefits over storing it as a buffer? Maybe you can link me to some of the code that handles this in Atom. I'm thinking that if we can speed up file open time, then we can add in a nice improvement for searching through files. When someone presses |
|
this 1 line (131090 characters long) of yaml causes the same problem i think |
|
Bump. I'm using a database prefiller skript that uses base64-coded images to store them in the database. It's only 3 images, but Atom editor hangs on loading. Even worse, after "killing" the editor using the "hang" dialog, the tree-view is missing. |
|
Loading a uglified react.js file created by browserify... it hangs. on MacAir, 4Gb RAM. |
|
Same here. I've optimized my AMD (RequireJS) modules, and the long lined "uglified" file makes Atom (1.0.3) freeze. |
|
Hi , I would like to contribute to github atom. Please help me how can I join with the discussion groups. It'l be a good experience for me to join with Github also while studying since I have experience in Opensource for some time. |
|
I fully realize that this is not an easy one to fix, but at the same time, it's quite awkward when I convince another colleague to use Atom and then it hangs indefinitely when they open a random file. From the looks of it, an intermediate solution would be to limit the line length at which the RE parser kicks in. After all, disabling syntax highlighting and linting is a lot better than going completely unresponsive. My gut feeling says that this would be a relatively straightforward patch. Any chance of getting it in for the time being? |
|
I agree with @timdp |
|
A solution I just discovered currently involves adding a .jshintignore to the app root with 'public/jquery.js' (or whatever the file is causing you issues) if you are running the jsHint package. Still a small hint of delay but i can say, no more messages asking to close the window or wait. Also turning on in the jsHint package, only run when .jshintconfig is found ( just find any default file out there ). |
|
Also, @hokein did some great work profiling typical invocations earlier in this thread. Below the |
|
Works on OSX and in the browser too. I don't know why long lines cause such a problem. This freezes my entire browser and pretty much prevents me from doing anything else. |
|
@timdp Yes, I'd also prefer having no linting over having to kill the whole editor... |
|
@derwaldgeist I'd prefer having no listing than having to kill my entire browser... (with not-exactly-restorable data) |
|
👍 for no linting in this case |
|
I think there should be a disable lint functionality in web Atom; or perhaps a persistent setting in HTML5 web storage. |
|
I don't think 'linting' has anything to do with this. Atom does not provide linting; it is provided by a third party package: https://github.com/atomlinter/linter. If you want to disable syntax highlighting, select |
|
I hope this is fixed soon. I pretty much can't edit HTML files on GitHub. On slow computers, it freezes me for 5 seconds every time I type a character. On my MBA, it freezes when I type a few characters I type, and then I have to close the browser. Is there a way to change atom into a raw text editor? Soft wrap or not, this issue has been dancing around for two years. I'm going to try and profile it and make a pull request (I've never seen a single line of Atom code... shouldn't this be at the top of the list?) |
|
Just to add, |
|
I'm already switched to Notepad++ . Didn't see much progression for this commonly required fix. Kinda dissappointed. |
|
I hate to recognize it, but I switched back to Sublime Text again... On Mon, 26 Oct 2015 at 13:55 yihaa5 notifications@github.com wrote:
|
|
Well i have switched to visual studio code ! Already |
|
I'm locking this thread for the time being — there's no value in notifying 35+ people about switching to another editor. Yes, this is definitely something that should be addressed (and it has to a certain extent), and is being worked on indirectly even though it might not be apparent. Increasing the performance of Atom is one of the top priorities. |
|
Atom should be able to open files with very large lines starting with Atom 1.16.0. |
|
We decided to back-port this fix to the current beta release, so it's available today in Atom 1.15.0-beta3. |
May be a known issue, but files with large embedded images such as github's public/enterprise/maintenance.html will often cause Atom to freeze (MacVim actually struggles as well).
Seems some of them (github's public/maintenance.html for instance) work fine when in soft wrap mode, or until you move your cursor to the long line when out of soft wrap.
The text was updated successfully, but these errors were encountered: