I continue to want to like Atom, and I try it out several times a year. Just updated, and see that it still has big performance problems on my system. I currently have BBEdit and SublimeText open for real work, and these are apps the have been running for days.
Here 100% would represent full usage of a CPU core:
BBEdit:
15 files open (various types/sizes)
76MB RAM
< 2% CPU
1 process
25MB app disk space
SublimeText:
10 files open (various types/sizes)
169 RAM
< 2% CPU
1 process
27MB app disk space
Atom
1 small Markdown file open
> 1.2GB RAM !!!!!!
> 85% CPU
7 processes
205MB app disk space
Just sitting in the background I am seeing Atom's CPU and RAM usages fluctuate wildly. The numbers above are the LOWEST I observed.
I will spend a little time looking into why this is happening. I certainly could be related to some add-on package that I have installed, but I don't every recall seeing BBEdit or SublimeText behave so poorly with all of the customizations I have thrown at them.
Update: added disk space for base app. Even with a 500GB SSD, Atom would make me think about its value vs space usage.
Update 2: the system specs. 2011 MacBook Pro 13-inch, 2.3GHz i5, 500GB SSD, 16GB RAM, OS X 10.11.2
Update 3: performed a clean reinstall of Atom, removed all third party packages, removed preference files, disabled Markdown preview. Atom is still using over 80% cpu and greater than 1GB RAM with one short markdown file open
Well, I kept digging and ultimately found a very long running issue thread[1] that mentioned having a .git directory in your home directory can cause high CPU.
Removing the three year old and accidentally created ~/.git directory and restarting Atom fixed the problem.
So now I will give Atom a deep new look.
Still, I am a bit perplexed, this is an issue that has been reported for nearly two years, and has not been fixed. I am not sure about the technical nature of the problem, but I think Atom, is trying to digest my entire 340GB home directory. Assuming that this is desired behavior, there should be at least a warning at launch about the issue. I am sure that MANY people have accidental ~/.git folders, and have a bad experience with Atom. At the vary least, it should not have taken me a couple hours of digging to find a solution buried in a GitHub issue.
While this fixes the issue on my MacBook, I am not sure about the Mac Mini, which I don't think will have a .git directory, but I will check later tonight.
That's surprising and sort of disappointing to me. I _just_ (within the last week or 2) was setting up my $HOME to be .git controlled...and was thinking "Maybe I should give Atom another shot"
That's good to know, next time I'm evaluating whether to switch text editors (which happens plenty) - I'll have to keep that in mind (or more importantly try and not discount Atom immediately because 'Oh yeah, doesn't it have a problem with $HOME/.git?')
Of course Atom is not the lightest editor out there but your figures are really strange: I'm using atom for one year now with dozens of installed plugin, currently working with more than 10 files opened at the same time with an up-time of 17days and I've never seen anything like you.
except one notorious bug when trying to open minified javascript files of hundred kB.
That's weird to have such a difference performance-wise between users, because it's based on chromium which does not suffer plateform specific performance drops I think.
For me the biggest problem here is the high CPU usage when the app should be idling. That KILLS battery life. I would not accept this behavior from high end video software, I certainly will not accept it from a text editor.
Following that the high RAM use can lead to swapping which will impact performance and battery live. As I said above after a clean install, and with just one short markdown file open, Atom is now using over 2GB RAM and Climbing. Fortunately, I have 16GB RAM on this system, otherwise I would already be swapping.
BBEdit and SublimeText never tax the CPU unless I am working with extremely large files, or doing search & replace on a huge number of files. I often will have 50 to 100 files open for days in these editors.
I like the evolving ecosystem of Atom, it now looks to be about on par with Sublime, and I can see that it will soon over take Sublime on that front. But it really need to get the resource utilization under control.
To be fair to Atom, I also tried installing it on a Mac Mini with an almost clean Mac OS X 10.11 installation. I had similar problems.
> BBEdit and SublimeText never tax the CPU unless I am working with extremely large files […] it really need to get the resource utilization under control
Neither does Atom for most users. It's not just n problem of «resource utilization», you're clearly facing a bug … Maybe you should consider submitting an issue (https://github.com/atom/atom/issues)
I see a number of current CPU related issues for Atom. I will look into using the performance diagnostic tools and see if I can contribute any new insights.
Again, I am see the issues on admittedly rather heavily customized workhorse MacBook (lots of Unix level tweets), AND on my stock Mac Mini. So I don't think this is a case isolated to just me.
I've had this happen too. For me, disabling a continuously-fading cursor plugin stopped most of my troubles with high CPU. Still kind of ridiculous that to animate the color on a few dozen pixels constantly took so much CPU in 2015, but I'm guessing it was forcing redraws or something. Note that this was on an rMBP with integrated graphics if that matters.
Atom Helper sometimes gets a mind of its own and runs rampant on the CPU, sometimes eating 100% of a single core even an i7 2015 MacBook Pro. Quiting Atom doesn't seem to stop Atom helper. It takes firing up the Activity Monitor and quitting them. It's ugly but it works.
Just tried VS Code, because I was curious... It seems to be using around 230MB of ram, and almost no CPU with a single file open... I was surprised how much better it worked compared to some of the other browser/nwjs/electron based editors. It's become my daily driver.
I am watching VS Code too. At the moment, Code's eco-system of add-on packages is missing too many tools I would want on a daily basis. However, I like the strong progress and road map, I could see Code being my go-to editor in the next year.
Actually, it has been a few months since I last checked on VS Code, I guess I should give it a spin again.
I use many of the features of Anaconda Python IDE. I know that better Python integration is high on the list priorities for VS Code, so I think this may happened.
I tested out VS Code, seemed nice enough. Hopefully it'll get the tight integration with Git that Atom has. I have a love / hate relationship with Atom right now.
If true it's somewhat disheartening to see that newer companies are still carrying on the tradition of limiting a product (not that Atom is a "product" per se) in favor of promoting another one. I think there's a name coined for it but I can't recall it at the moment.
Weird. I don't get that on my system. Memory usage (according to top) is somewhere around 200 - 300 MB, cpu usage runs somewhere around 25% of a single core (on an i7).
The only time I get real lag on my system is when I'm opening a really, really large and minimized / mangled javascript file. Occasionally I get problems with the minimap or linters on very long files, but I have started regularly working with source files in the 5k - 10k lines range. I inherited and am refactoring and breaking down some monolithic stuff into more modular code, so there's a lot of tabbing around and copypasta in addition to regular coding, and atom's been responsive.
The thing I like about atom is that there's a pretty robust plugin ecosystem already.
It makes sense within the context of the Atom dream: to make a completely customizable editor, down to the pixel.
But Emacs has almost the exact same dream: to make a completely customizable editor, down to the character-grid cell.
This one small difference gives it way more performance, without much loss in my opinion.
Atom is extremely bloated in every sense of the term. It's bloated in CPU, in memory usage, in files, in libraries, in dependencies, in overall performance, in everything.
All because it wants to be customizable on the pixel level, rather than the character level.
I wish a new editor would arise to actually complete with Emacs. I hate this piece of junk editor, but it works, and it gets the job done.
I don't think pixel level customization is a major factor in bloat or performance. Doing it on top of a browser is what adds the majority of the overhead IMO.
How come Atom is slow for so many people? Visual Studio Code is based on Electron as well and doesn't seem to have that.
I tried VSCode for TypeScript and it was very smooth, not as good as Pycharm for my usecase though
Completely out of curiosity I checked the status of my emacs server:
189 opened buffers (4 terminal sessions, rest are mixture of Ruby, Clojure, Javascript and Elisp files)
< 1% CPU
2 processes (server + attached editor)
no idea about disk space probably around 100MB
It has zero effect on my workflow though. I can run Chrome, Safari (for testing), Outlook, Slack, music streaming, etc. without any slowdown when developing with Atom.
Edit: Just checked, after using Atom for two days straight it is currently occupying 80MB of ram. Anecdotally, the claim that Atom is a resource hog is actually wrong.
I'm on the same boat, as much as I'd love to love Atom, I keep installing it anew with every release only to get disappointed by the performance. Shame because it's an otherwise great editor.
I think the markdown-preview plugin may have issues because once I get to about a 400-500 line file it pegs my i5 at 100% CPU and takes 5-6 real life seconds to enter a single character.
This is on Linux. Other than that, I would say performance is reasonable on all projects I've worked with (couple hundred files in a folder while actively editing a handful at a time).
Thank goodness. I was beginning to think it was just me.
I'm in the exact same boat. Other people tell me they like Atom and every single time I try to use it my system thinks I just set a vampire on the CPU.
That seem pretty atypical... I'm trying everything I can think of, and I can't get the CPU above 40% utilization (and that was just a temporary spike while searching a massive directory of files).
For me, Atom idles at 0.5% CPU. 10 files open, 130MB of memory being consumed.
I'm fairly sensitive to slowness for an editor. Earlier versions of Atom had too much noticeable lag. Recently, though, it seems pretty performant.
Here is a way to reproduce an issue. Put syntax highlighing on discover.
Open a 1000 line json file. Most of the issues are on syntax highlighting. The editor has a very bad way of inplementing this, based on it always crashing or timing out.
The edit window closed, but to be fair I need to mention that the from 1.3 - 1.4(the new update), I opened the exact file I had significant problems with.
The editor used to bottle neck, hang, and usually would just quit after being non-responsive.
This has been fixed. The editor would take ~45-60 seconds (I timed it when i logged the issue on github). It now takes ~3 seconds. Sublimetext comparatively, is a bit better at <3 seconds, atom takes about 3-5 seconds and shakes out the highlighting over another 1 or 2. In total, you can start working on the file in about 4 seconds which is a big improvement over never/1 minute.
The decision to base Atom on web technologies remains controversial and it's still not as snappy as Sublime, for example, for similar tasks. But I think that decision has been vindicated by the speed of development it's made possible. Since the bar to entry for contributors is so low the ecosystem that's developed around Atom is second to none. You can find a package for just about anything and the UI polish of a lot of these packages is much higher than I've seen for any other editor, thanks to the ability to leverage modern HTML, CSS & JS.
Atom may never be as fast as a truly native client but it's perfectly usable now and is increasingly leaving the competition in the dust when it comes to features.
I'm not sure Atom's slowness can be attributed to being built on web technologies. Visual Studio Code is also built on Electron and is not only faster than Atom for many tasks, but also faster than Sublime. To be more specific, on my windows machine at work I can open large files (10+ MB XML) much quicker in Code than Sublime. Global text substitution in these large files are also noticeably faster in VS Code.
> Visual Studio Code is also built on Electron and is not only faster than Atom for many tasks, but also faster than Sublime.
Can you please back this up with any benchmarks?
2 months ago when I tried VSC, though the UI and some features (git workflow) were really nice, performance was again a disappointment compared to Sublime. Having played with Electron myself it's obvious why performance is an issue with both Atom and VSC.
Agreed it's slower than Sublime, but seems to have more in the box too... There are also some quirks that I haven't liked, but it's become my day to day editor over sublime at this point... I like the UI a lot.
I currently use Atom as my primary editor for creating http://clara.io on all machines, switching away from Sublime. Two issues stand out in my basic usage:
- Atom fairly regularly freezes on me -- probably once every two days such that I have to force kill it.
- It also is very very slow opening large files (+1M files), probably at least 5x slower than Sublime in that regards.
This is some of the best news I have heard in a while. I really wanted to love atom, but just couldn't wrap my head around the decision to use coffeescript
For all the extensibility and speed of development, the Atom ecosystem is still missing features I can find in any other major editor. Off the top of my head, there's no way to automatically (hard) word-wrap text. The vim plugins only implement the basics, and they all seem to be missing the command bar entirely.
Which plugin? The only ones I could find required using a keyboard shortcut to format the current line, rather than wrapping as you type. In vim the equivalent would be :set wrap.
The development of Atom shows a common anti pattern of software development: choosing the technology first. The goal was to develop an editor with web technologies, and not to develop the best editor in the world. The result is as sad as foreseeable: a buggy and slow memory hog named Atom. When I tried it last time, a couple of days ago, it was impossible to enter an @ sign into the text area.
The problem is that "best" is subjective. I think one could more accurately say that they're trying to develop an editor that is easily extensible with technologies familiar to many developers.
i.e. your perception of what they want Atom to be and the reality of what they want Atom to be are probably not the same.
My take? Revisit this in five years. I bet it'll be one of the richest ecosystems in software development. As one who has written Atom plugins (live unit testing w/ real-time feedback), I've never encountered such a developer experience until Atom.
Lets say if one of the main goals was to build a very easily extensible editor, one might still choose to build it on web technologies.
While I don't use atom, I can see the reasoning. Since I'm comfortable with webdev, the barrier to entry for extending atom is much lower compared to other newish editors.
I assume their goal is to someday integrate Atom into GitHub proper (running in a normal web browser) in order to have developers living in a 100% GitHub ecosystem. The chosen stack makes a lot of sense given this objective.
I'm really enjoying the innovation that is happening in text editing. I prefer Visual Studio Code for light weight editing. Both Atom and VS Code are built on the Electron [1] engine but "VSCode uses Monaco for the user interface, not Atom. It is the web editor which Microsoft developed for Visual Studio Online. Electron is just the common core between the two applications. You can think of it like different programs using the same .NET framework, or two games built on top of the same engine." [2]
Both are fine editors and I use both [Ubuntu versions] in different contexts. It's fantastic that both are open source. That's were Sublime Text 3 loses me, because it is proprietary. I agree with some of the concerns raised in this thread, but realize some see closed source with one benevolent dictator for life as a benefit [3]. Other editors I'm keeping and eye on are Adobe Brackets and Facebook's Nuclide. LightTable is interesting. I have given vim and emacs a spin, but I am not a keyboard jockey. Aint we got fun!
Brackets was quite nice for what it can do out of the box, but I found the community support very poor, so there's really not much more than that it can do.
LightTable was a clever idea that never quite fit my workflow, and which as far as I can tell is basically dead. The creators have abandoned it, and the surviving maintainer support is of the "pull requests welcome" variety. There are glaring bugs in basic features like inline eval, and maintainer response was a combination of "eh, we're cutting that feature anyway" and "fix it yourself."
Sure as hell doesn't give me any hope that this "Eve" thing their hyping is anything but smoke and mirrors.
I'm still using and prefer Brackets. Starting using it because it's performance was better than any other prior to VS Code.
However, Brackets new instant search is awesome and no other editor has it. For large projects I find it a great feature to be able to search all files in realtime as you type.
Unless I'm totally missing the point of the instant search feature, this is definitely something you can do in Emacs[1], and something I believe I've seen co-workers do in Sublime.
At a cursory glance, I'm not sure it is the same. Brackets keeps some type of index. So there is zero delay whenever you perform a project wide search.
Looks like Emacs helm uses Silver Searcher which is real time, but impressively fast.
Oh yeah, performance-wise I'd say it beats either Atom or VS Code right out the gate. I just never managed to get an environment set up for what I needed to do at the time (ES6/Clojure[script]) so it wasn't much use.
Haven't tried it since launch, and while it's still insanely HUGE for a "text editor", I find it much faster. It was unusable back then, now it seems to work. Startup time used to be longer than the OS itself (well, not really, but you get the point), now it's somewhat reasonable.
Do you use "in production"? Is it OK?
By the way, Find seems to be only working on three or more characters? How do I find two-letter substring? :)
edit: Regexp find is a bit slow overall (one 5-line file). Like it is waiting for a while before commiting to updating the UI. And that's on an i7 desktop, can't imagine it working on my Celeron laptop (but will give it a try later).
The install size doesn't bother me personally (although my colleague's with newer Macbook Pro and smaller SSD may have an other opinion) but the speed of the editor is important for me.
It is fine for smaller simple files but I have had occasions that with some text files it can be really slow to a point that it is unworkable.
Last I was working on a HTML5 game and I copied the base64 encoded version of a font into my file that handled the assets and boy was that a bad idea. The preload.js was just 49KB but one big base64 encoded line made atom choke... Textwrangler or sublime didn't crimp on the same file and opened it in an instant.
Granted my Macbook Pro is old but a i7 with 8Gb RAM should be able to deal with these kind of situations.
find/replace works fine, and it's an XML file so syntax highlighting is working great (although it does take a few hundred ms to actually apply the syntax highlighting after a lot of scrolling)
It did take about 2 seconds to load the file though, so you can make fun of that!
On a more constructive note, I've found that it does have significant problems with certain text structures, namely really long single lines.
Just the other day I had to debug a json serializer, so my q&d solution was to copy the text out of the eclipse debugger, paste it into Atom (as it was already open), then find my way to the section I was looking for. After significant delays getting to the spot I needed with 'find', any use of the left and right arrows to navigate the text further was accompanied by a ~5 second delay per character. The same operation in Notepad++ went smooth as butter.
I'm not sure specifically what it is, but it seems longer lines just wreck the performance.
I've seen a few commits talking about fixing specific problems that have caused this in the past, leaving me to think that it's most likely either one or more of my plugins causing the issue, but i just haven't cared enough to look into it yet.
Just like you I keep Notepad++ around for my "quick" needs (open a file for less than a minute) and for big files that aren't "code-ish" (they have long lines), and then atom is used for everything else.
Switched to atom about a month ago.
Been using it on a large project and it performs great (the ctags file is 344MB, but symbol navigation has no hiccups).
I still miss a few features from my previous editor (notepad++ on wine), such as the comments-only spell-checker and macros.
But overall I'm happy with the transition.
Linter's work quite nicely (at least the Haskell, Bash, and Python ones). And git integration is useful.
As usual with these highly modular text-editors, batteries are not included, and getting a good environment going can take up quite a while.
Been using it in production for about half a year now and it's great. The customizability and package system are much better than in Sublime (which was already good to begin with). That was the main reason for switching.
Performance has improved a lot. I don't care much about startup times, because I only start it once a week and then keep it running, but the rendering speed, too, has gotten much better.
The only thing I'm really still missing is column select.
I'm using Atom on a daily basis, alongside with Emacs. It works quite well. There's some crashs due to Samba filesystems, but apart from that I haven't had blocking issues for a few months.
Maybe a single thing bothers me: the search and replace UI wasn't very good the last time I checked, especially when trying to replace inside a selection.
What's your setup with Emacs? As an Emacs user with Atom installed I'm curious in learning more about your setup & how I might use multiple editors as well.
I've been using Atom since day 1 (I never really loved Sublime) and it's gotten considerably faster. Still, if I have a particularly huge file—especially one with syntax highlighting—I still just reach for Sublime.
I find the momentum which Atom has gathered to be impressive. It seems to be building up an ecosystem at quite a rapid speed.
Myself, I prefer Emacs, because I like it's base philosophy (everything is a text-buffer, everything is hackable LISP) and the endless possibilities that provides in form of customization, extensions (and extension on extensions, and customization of those, etc etc).
I don't think Atom is quite there, or ever will be. It will be interesting to see if if has the staying power of Emacs, or if it will yet another TextMate, Sublime Text or whatever hip text-editor of the month there has been the last decade.
On mobile so forgive my short reply. I just don't understand why you were getting down voted.
I too use Emacs, and another reply mentions that you have to learn Emacs (Elisp, etc) to program your thremes which is just plain incorrect. (See: https://github.com/mkaito/base16-emacs)
I'm a newish user of Emacs (around two years) having switched from sublime text. I can safely say I don't know much about elisp at all, but hope to some day.
I am never stuck in my ways, and always seek out tools that get the job done. Atom is actually quite impressive. Most of my co-workers use it on a daily basis (for JavaScript development).
... Man editing text in HN mobile blows in this tiny ass text box.
What keeps me in Emacs is it's philosophy as you said. There is a nice uniformity that the editor provides, and I can do practically anything. Atom has nearly stolen me from Emacs, but there are some issues in the past with some commands that have kept me from switching.
Let's see if this new version puts Emacs in my past.
Absolutely. Their mistake was not making it open source sooner and the development is going very slow, too.
It was inevitable that once a good cross-platform open source editor is available many people would jump ship.
ST is a great editor, but Atom has already surpassed it in most categories, thanks to the community. You can't beat that with a small team working on a closed source editor.
The rate at which new plugins are developed (and maintained) for it maybe? Does it support xyz?
To me, editors are on their way "out" if they can't keep up with the new languages / etc. Sublime text isn't going anywhere quickly. It can do a lot of things. If it can't keep up with other text editors it will still be usable, but may not be best option for everything.
People value notepad/nano for quick editing.
What role will sublime text play once a "superior" text editor comes into play?
I mean, you have to code your themes, therefore you have to know much stuff about the editor. In many IDEs you can just load a them and get a config UI that lets you fine-tune it.
Emacs has extensive preference setting functionality. There's lots of fine-grained configuration you can do, including themes, colors and fonts, without writing a line of elisp.
That said, elisp is fun to learn, no harder than JavaScript, and you can get pretty far customizing Emacs knowing just the basics.
I've heard that Atom doesn't really reuse CSS or (SASS/LESS sheet variables) in any meaningful way, meaning having consistent theming is hard, at least if you want to use extra modules and plugins.
Atom: Now one step closer to being emacs. Now all you need is a proper text buffer model, instead of the clumsy hack you've got now, and lisp as an extlang. Wait, you already have that because clojurescript. So now you just need better APIs, and a proper buffer model.
While I am a diehard emacs user, I considered using atom for light editing (short enough that I'd want proper highlighting/indent support, but not long enough to get emacs out), but the lack of uniform buffer treatment was a dealbreaker for me. If you can't switch between settings and terminal screens using the same mechanism you switch between text screens with, and it all of the above don't have the same underlying mechanism, than you're doing it wrong.
Do you know of any examples out there on how to write plugins using ClojureScript? I got into Emacs a few months ago, but have been considering switching over to Atom so I can write plugins in CLJS
One thing I noticed about Atom is that it doesn't handle (or preserve) Byte-Order-Mark and that wrecked havok on one of Unity project I was editing before.
I liked the design of Atom, but for this reason, I guess it's not the time for me to give up Emacs yet
Atom still sometimes freezes for me (on computer with high-end specs). Opening large text files also makes Atom freeze. The built in spotlight thing is slow for bigger projects (expected). The overall performance has definitely improved though.
I personally use Atom for lighter development and enjoy how easily accessible plugins are. Very easy to install support for lint tools/editorconfig/snippets/&tc.
It's better, but it's still not useable at a professional level. For example, a simple task such as CMD-D to create multiple cursors in a file. Sublime text screams through the file creating the cursors. Atom is like swimming in syrup. I wish Atom well, it's an amazing piece of software. But the developers chose a dev-stack that suited them instead of one that suited the end users of the software. So it will never take over the world as it could have. See also Discourse.
I found it a little "bouncy" on first pass. It felt like there was an edge-of-perceptible lag when updating the display in response to keypresses. I tried switching to it again recently, and that's completely gone now. I guess it's just a tad on the slow side starting up, but everything else is really great, and I'm definitely sticking with it this time.
Note that Atom doesn't seem to preserve session through restart. I'm quite used to use sublime as notepad without actually saving anything. Maybe there's an option for that though.
> The Linux version does not currently automatically update so you will need to repeat these steps to upgrade to future releases.
Bit of a shame, I wouldn't have known about this update if I hadn't seen it here. While I appreciate auto-updating isn't for everyone, an in-app notification would have been useful.
I really like the idea behind Atom, it's what I "want" to like. But Sublime is just so superior in terms of speed and feel that I keep going back. Working in Atom has that feel as if I was sitting in a remote desktop view while coding.
I think the line between "IDE" and "Editor" is starting to blur, and Atom is toward the IDE side of that scale.
I personally still use Notepad++ as my "editor". Quick things like a git commit, just looking over a single log file or something, etc... Basically when i don't plan to be using it for more than a few minutes.
Atom comes out when i do development. It's more-or-less my IDE at this point. And when viewed through that lense, it starts faster than jetbrains does!
This. I was using WebStorm for a while, but with all the inline jshint support and es6 support, atom has been really nice. I have a strange issue where [esc] doesn't close my search box, but other than that and the CPU usage it's been great. I wanted rainbow brackets for a long time, and it finally looks like someone's done it: https://atom.io/packages/swackets
Me too, but I think I will settle with Atom eventually. Price of the sublime itself is acceptable, but then also sftp plugin is another $30... Or is there some other worthwhile alternative?
Vim? Takes some setting up/learning but everything I ever wanted is 'out there'. Amazing plugins for git, linting, code completion, whatever you can think of some one has done/is doing. I used to use Textmate a lot, tried sublime, Atom etc. I'll never go back. (Sorry, but someone had to be 'that guy'.)
I've been a happy vim user for 10+ years.
I took Atom for a spin last week and I absolutely love it. There's a vim mode package for Atom that implements some vim features (not all, obviously) here https://github.com/atom/vim-mode
Sublime is also closed source (I could live with that alone) and somewhat secretly developed. Releases seem random. ST3 is, in my opinion, worse than ST2. It's acceptable for beta, but I don't know what happens with ST2 now. Am I stuck without updates? What was the point of major version change in the first place?
I try it again every few versions and would really like to try Atom for longer but it really bothers me that I can't really configure hot exit the way I want it to work.
It seems like I'm a minority in that I don't want Atom to open the whole folder in the tree view when I open a file.
What annoys me even more is that I want hot exit completely disabled, so that when I open Atom, no previous files/tabs or folders are open. I could never get this to work. The previously opened folder will always be present in the tree view when I open Atom again and when I open a file it will always open the folder in the tree view.
Does someone know if there is a workaround to this?
I've been using atom for a few weeks. On my low-power 12" MacBook, it is only slightly slower than sublime text. The only two tasks that are annoyingly slow are opening the editor or a new editor window.
The barely noticeable lack of snappiness during editing is more than compensated for by the quality of the editor and its plugin ecosystem. I've also started using a ligature font for programming, which sublime doesn't support.
So many of those commits are "updated readme", "updated changelog" and stuff like that. Scrolling through the log it's not uncomming to find 5 or 6 "updated readme" commits right after each other in that repository.
It's not a good metric. Instead look at the 278 lines of code necessary to achieve it.
:)
I get you perfectly, but every exensible system usually has a couple of corners that are not that easily extended as indented. Design choices, tradeoffs or laziness usually involved.
Disappointed to see so much FUD over here. I switched to atom from sublime 2 months back, mainly because its tooling for ES7(emmet, babel, eslint etc) just works. And the editor is much more accessible to me than sublime.
Btw, I develop on an 14'' i3 3rd gen, 8gig, no-ssd laptop, and I am able to do react-native dev, with the emulator running just fine
I setup the dev team of a startup(in Delhi, India) I was consulting with with Atom for react and node dev few months back. These guys were provided pretty shitty, and pretty old, 4 gig ram laptops. And they used to screw up things which could've easily been resolved with in-text-editor linting. I got them running atom with emmet, babel and ESlint, and they are still using it without any issues.
I have seen atom run reasonably well on reallyshitty machines. Its very hard for me to accept that all this complaining about its performance is not FUD.
I suspect those who are experiencing high cpu usage while idling are running into weird bugs. It's only been 6 months since they released 1.0.
It runs well enough on my laptop with a 4th gen i7, 8gb ram, ssd, running linux but cpu utilization is rather high. Scrolling inside a moderately sized file puts a 20-30% load on all 4 of my threads. If I enable on the fly linting, autocomplete features, minimap, and etc, it starts to add up.
I've used vim, emacs, and sublime text and I've found that with my uses cases (mainly python development), atom ranks at the bottom of efficiency and performance (but highest in productivity). I consider myself a proponent of atom and it's currently my favorite editor, especially with vim-mode but it has it's drawbacks. It's just not a fair fight; comparing the performance/efficiency of atom to editors written in c/c++ doesn't make sense to me.
I love Atom and I've been using it for a long time now, but have they fixed the horrible stability issues in Windows yet? I run it on 3 distinct Windows machines and they all experience the same issues (most notably, I cannot have two editors open without the most recent crashing).
I love Atom, but it along with Chrome it eats all my memory with just a few open files/tabs! Why would an editor and a thin (!) client use gigabytes of RAM?! Remember when computers had just 48KB of RAM and did great things?
Posting to say I love Atom and I am excited for its future. I've added Facebook's Nuclide package and it has some really great features. Would love to continue to see Atom as a full featured IDE
As a front-end web developer that has used Emacs for several years, I often feel the pull to Atom. It draws very clear, direct inspiration from Emacs.
Spacemacs is an improvement, however I think it the biggest advantage it (and any other modern text editor) has over Emacs is the on-boarding process and general beginner friendliness.
Beyond that, Atom's modes for front-end web development are pretty top notch. We have js2-mode, and web-mode in Emacs, but the overall experience in Atom is often superior. For example, it's extremely easy to quickly install a color-picker, pull open a CSS file, and use a color wheel to make a hex value slightly darker. More, the color-picker UI feels tightly integrated into the editor.
On the surface, this feels trite, however the slow build-up of user friendly developer conveniences adds up.
The general command over the entire environment continues to draw me back to Emacs. Still, I continue to watch for when Atom can achieve this.
Does anybody know if it's now possible to use Atom as a sane $GIT_EDITOR (or $SUDO_EDITOR...) such that a new tab is opened in an existing window and the invoking process (git, sudo,...) is notified when the tab is closed (similar to Sublime Text)?
I use the 'atom --wait' command line option to do this and it's worked fine as an EDITOR so far, though I don't use atom much otherwise, so I never have a lot of tabs open.
I've stopped using atom due to horrendous latency issues. Pretty disappointed. Would really love a modern open source text editor, but noticeable lag between pressing a key and having it appear on the screen is a no go.
With all the people complaining about Atom performance, I cannot confirm this. Switched from Sublime Text about two years ago and never had speed/snappiness issues. If anything Atom does quite well with gigantic files.
On a 500 line file when I start adding multiple cursors, after the 5th or so It starts taking multiple seconds just to select the next. This was in December, so a recent version. I can't work like this.
Here 100% would represent full usage of a CPU core:
BBEdit:
SublimeText: Atom Just sitting in the background I am seeing Atom's CPU and RAM usages fluctuate wildly. The numbers above are the LOWEST I observed.I will spend a little time looking into why this is happening. I certainly could be related to some add-on package that I have installed, but I don't every recall seeing BBEdit or SublimeText behave so poorly with all of the customizations I have thrown at them.
Update: added disk space for base app. Even with a 500GB SSD, Atom would make me think about its value vs space usage.
Update 2: the system specs. 2011 MacBook Pro 13-inch, 2.3GHz i5, 500GB SSD, 16GB RAM, OS X 10.11.2
Update 3: performed a clean reinstall of Atom, removed all third party packages, removed preference files, disabled Markdown preview. Atom is still using over 80% cpu and greater than 1GB RAM with one short markdown file open