Live data from Hacker News

Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

blog.atom.io

81–90 of 176 posts

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#81

Earlier quoted context omitted.

Tested with a real XML file here: # wc -l t.xml 315479 t.xml # wc -c t.xml 10377128 t.xml Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Opens quite fast, too. Editing, cursor movement, pagination, etc. all super fast. OS X 10.11.3, Atom 1.6.0 on a MacBook Pro (Retina mid-2015, 2.8GHz Core i7, 16GB RAM, AMD Radeon R9 M370X).

Interesting -- disabling the xml plugin significantly improves performance for me (but I lose syntax highlighting).

Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#82
post #73

Earlier quoted context omitted.

> went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance. Pfft, 1000 lines of code? If Atom couldn't handle tiny files like that, you couldn't even call it an editor. Try working with a 10-20k+ line file (very common for me when looking at compiler output) and your heart will skip a beat when you realize that you had unsaved changes in another file bef…

Ok sure, I opened up a 1000 SLOC file and copied until it was a 20,000 SLOC file, and performance was still fine. So I made it a 60,000 SLOC file. This time there was a small drop in perf as the editor caught up then it was fine again (not sluggish at all when editing the file). Are you taking this compiler log from a remote build server? AS in that case it's your network that is the bottleneck as the file is copied…

No, the file is not on a network; I don't get why you are in such disbelief... HN complains about a lot of things, but this is pretty cut and dry. I just opened a 2.4MB, 28425 line file containing LLVM IR, and it locks up just scrolling through the file, and the highlighter totally gave up and none of it is colored no matter how many times I try to get it to highlight it. Cutting it down to 5k lines gets me highlighting.

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#83
post #59

Earlier quoted context omitted.

Nope, completely wrong. I have a 32GB i7-4790K at around 4Ghz or so, and Atom is a complete dog. The painful truth is that a webview is never going to beat a native app at this kind of task. It's not a vocal minority. Atom is painful to use compared to, say, Sublime.

You expect me to believe that with those specs Atom really runs like a 'complete dog'? The fact you also mention Sublime too really just tells me that your opinion was biased from the start. Finally, JIT compiled languages can be just as fast as native, simply because they can optimise to your hardware specs. You are getting mixed up as to why things are the way they are; JavaScript is a dynamically typed language, s…

I don't think it's a JIT vs native issue, it's more likely from native UI components vs DOM. I'm sure JS as a language is plenty fast enough, but the DOM adds overhead that kills that. But this is just speculation on my part as I've barely tried Atom.

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#84

Earlier quoted context omitted.

Interesting -- disabling the xml plugin significantly improves performance for me (but I lose syntax highlighting).

Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.

> Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.

Yes, I'm using the built-in language-xml version 0.34.2.

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#85
post #54

I love the concept of Atom and have a lot invested in its success. That being said, I switched back to Sublime because of the responsiveness, and here's why: Programming (for me) is a craft. When I'm in the flow of coding, there's a conversation between me and my program, mediated through the editor (and my REPL). Even a subtle typing lag is enough to subtly disrupt that flow state – the speed of thought and text no…

I'm curious how much time you spent with it before switching back? When it first launches, coming over from Sublime Text or Vim or whatever definitely feels different, but in my experience after a day or so the lag became totally invisible and all of the other Atom features started to shine through, leading me to stay. (Note however, that this is post v1.0. If you haven't checked it out in a while there have been some really great perf improvements.)

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#86

Earlier quoted context omitted.

I just tried opening a 6.3 meg xml file, and Atom was almost unusably slow. Sublime Text opened the file almost immediately and was responsive off the bat.

Tested with a real XML file here: # wc -l t.xml 315479 t.xml # wc -c t.xml 10377128 t.xml Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Opens quite fast, too. Editing, cursor movement, pagination, etc. all super fast. OS X 10.11.3, Atom 1.6.0 on a MacBook Pro (Retina mid-2015, 2.8GHz Core i7, 16GB RAM, AMD Radeon R9 M370X).

> Unlike Sublime, it doesn't syntax highlight for some reason, but it does open.

Perhaps Atom is disabling syntax highlighting for sufficiently large files?

Edit: Interesting experiment. Open a small xml file, and syntax highlighting is active. Open a large xml file, and Atom doesn't syntax highlight. Copy and paste the contents of the large xml file without highlighting into the small file with highlighting, and after the text is copied there is a massive slowdown as Atom syntax highlights. I was able to scroll down the file and watch the syntax highlighting slowly propagate through the file.

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#87
post #82

Earlier quoted context omitted.

Ok sure, I opened up a 1000 SLOC file and copied until it was a 20,000 SLOC file, and performance was still fine. So I made it a 60,000 SLOC file. This time there was a small drop in perf as the editor caught up then it was fine again (not sluggish at all when editing the file). Are you taking this compiler log from a remote build server? AS in that case it's your network that is the bottleneck as the file is copied…

No, the file is not on a network; I don't get why you are in such disbelief... HN complains about a lot of things, but this is pretty cut and dry. I just opened a 2.4MB, 28425 line file containing LLVM IR, and it locks up just scrolling through the file, and the highlighter totally gave up and none of it is colored no matter how many times I try to get it to highlight it. Cutting it down to 5k lines gets me highlight…

No! You must be lying! I just opened a file and experienced none of that. Therefore it is patently impossible for you to be experiencing what you say you are! /s

Didn't we get enough of this BS in the era where people were "victim-blaming" over BSODs in Windows because "I've never had a BSOD and I've been running Windows for years?"

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#88
post #47

Earlier quoted context omitted.

* Cross-platform with a pleasing (to me) GUI. Specifically, I appreciate the ability to have multiple views including rendered previews of particular files. * "Feels right". The ergonomics of the keyboard interaction Just Work for me. * Excellent git integration (with plugins) which is frankly abnormal on editors that run on Windows as well as ix (or Windows at all - the git story on Windows is still pretty crappy).…

Visual Studio has Git support built in...

Man, what a surprisingly useful comment. You have really changed how I feel about this subject 100%.

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#89
post #54

I love the concept of Atom and have a lot invested in its success. That being said, I switched back to Sublime because of the responsiveness, and here's why: Programming (for me) is a craft. When I'm in the flow of coding, there's a conversation between me and my program, mediated through the editor (and my REPL). Even a subtle typing lag is enough to subtly disrupt that flow state – the speed of thought and text no…

I've had the same feeling about the startup speed issue, but with javascript / typescript, I've found that Visual Studio Code occupies the middle in startup performance, and I've found the "intellisense" information to take a load off the mental difficulty of work and memory.

So now I use Sublime to make quick edits, but for anything longer, I use Visual Studio Code.

Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

#90
post #34
post #10

I have been ignoring the Atom hype because "geeze a programmers editor written as a big blob of JavaScript on my desktop that sounds like a dumb idea". Then I tried it and it's wonderful and magical.

We actually forked Atom and built an email app. It's worked surprisingly well!

Why a fork of Atom rather than a brand new Electron app?
Post reply on HN