Atom text editor 1.4 released(github.com)
github.com
Atom text editor 1.4 released
https://github.com/atom/atom/releases/tag/v1.4.0
203 comments
SOLUTION to high CPU!
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.
[1] https://github.com/atom/atom/issues/3426#issuecomment-119780...
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.
[1] https://github.com/atom/atom/issues/3426#issuecomment-119780...
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"
The GitHub issue the I created for Atom was closed almost right away with the comment that this problem has been fixed in the Atom 1.5 beta.
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.
Do you have issues with Google Chrome also ?
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.
Do you have issues with Google Chrome also ?
I do not have any issues with Chrome.
To summarize my above findings.
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.
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)
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.
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.
As noted in this thread, I solved my problem, and filed an issue: https://github.com/atom/atom/issues/10421
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.
I looked for the "continuously-fading cursor plugin" but found nothing. Is this built-in or an add-on?
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.
Actually, it has been a few months since I last checked on VS Code, I guess I should give it a spin again.
Just curious, what kinds of tools are essential for you to switch?
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.
http://damnwidget.github.io/anaconda/#
http://damnwidget.github.io/anaconda/#
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.
VS Code has much better git integration than Atom will ever have out of the box because Atom does not want to compete with GitHub for Desktop.
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.
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.
This is the exact reason I don't use Atom.
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.
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.
(I haven't used Atom)
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
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
Funny you mention that. I am thinking about switching. Vsc is much more performant built on electron which was what github developed to write atom.
So microsoft did a great job. Issue is that there is a much smaller community, less plugins and I have mac so no other ms synergy for me.
That said, I am going to try ot again today. I liked it
So microsoft did a great job. Issue is that there is a much smaller community, less plugins and I have mac so no other ms synergy for me.
That said, I am going to try ot again today. I liked it
I have no idea what MS pulled to make Electron fast, because all other Electron-based apps that I've used have been absurdly slow.
VS Code isn't the fastest thing ever and uses more RAM than I'd like, but it definitely hits tolerable performance for me.
It's definitely the exception rather than the norm. I wish they'd publish something about writing efficient Electron apps.
VS Code isn't the fastest thing ever and uses more RAM than I'd like, but it definitely hits tolerable performance for me.
It's definitely the exception rather than the norm. I wish they'd publish something about writing efficient Electron apps.
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 100MBAnecdotally, Atom runs fine on my MBP from 2012... Sure it's a bit of a hog resource wise, but I find that the benefits outweigh the cons.
> Sure it's a bit of a hog resource wise
I think that's his point. To some people, like leejoramo, if their text editor is a resource hog then it is not running fine.
I think that's his point. To some people, like leejoramo, if their text editor is a resource hog then it is not running fine.
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.
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.
If you are running on battery power, the demands of Atom over something like BBEdit is a pretty big deal.
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).
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).
I didn't have a preview window open, but still tried disabling the core markdown-preview plugin. Unfortunately, no improvement.
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.
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.
See my solution elsewhere in this thread. You might have a ~/.git directory like I did.
Just checked and that doesn't seem to be it for me.
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.
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.
Problem is fixed if sh is plaintext
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.
Problem is fixed if sh is plaintext
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 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.
I'm curious how this compares to the browsers that use the same core technology that Atom uses.
3 projects open in separate windows with over 30 files being edited: http://imgur.com/uK7KbO8
There's something seriously wrong with your system's compatibility with Atom.
There's something seriously wrong with your system's compatibility with Atom.
How about use dtrace to root cause the issue?
Look at file io, socket io patterns.
Look at file io, socket io patterns.
[deleted]
I downloaded Atom as a cool new thing to maybe use on my netbook.
It was more resource intensive than Visual Studio 2013 Community Edition lol.
It was more resource intensive than Visual Studio 2013 Community Edition lol.
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.
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.
EDIT: s/flow/workflow
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.
EDIT: s/flow/workflow
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 haven't used Atom yet but I'm certainly willing to try. It doesn't have to be fast as native, just fast enough.
"Leaving the competition in the dust" sounds a bit like hyperbole. Can someone provide a better comparison?
Code completion? Multiple cursors? "Ace jump" ... navigation in general. I guess "precision editing" encompasses what I'm trying to say.
https://vimeo.com/53144573
"Leaving the competition in the dust" sounds a bit like hyperbole. Can someone provide a better comparison?
Code completion? Multiple cursors? "Ace jump" ... navigation in general. I guess "precision editing" encompasses what I'm trying to say.
https://vimeo.com/53144573
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.
- 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.
> Since the bar to entry for contributors is so low
Have they switched from Coffeescript to JavaScript?
Have they switched from Coffeescript to JavaScript?
That's a really big deal. I wanted to fix a bug or two and saw coffee last year and noped out. Glad to hear they are going back on that one.
Kind of curious why they made that decision in the first place.
Oh, they are a Ruby shop. Right.
Kind of curious why they made that decision in the first place.
Oh, they are a Ruby shop. Right.
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
I assume ES6 didn't exist at the time (or wasn't feasible to use). If you're not used to javascript it can be quite annoying to develop in.
I think it's still a work in progress. I still see .coffee files in atom/src.
All new code is in ES6+ rather than CoffeeScript, which is significant.
Cool. Got to resurrect my plugins :)
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.
Here's a nice plugin to add the vim command bar: https://atom.io/packages/atom-vim-colon-command-on-command-p...
Sadly that only supports four simple commands.
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.
> not to develop the best editor in the world.
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.
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.
> choosing the technology first
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.
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.
Yeah. I don't want to rail against it top much because it is a free tool, but it crashes regularly, hangs, and regularly lags opening small files.
I love the drag/drop sidebar but If this update doesn't inprove the editor significantly, i will delete it.
I love the drag/drop sidebar but If this update doesn't inprove the editor significantly, i will delete it.
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 can only agree.
Please note: https://github.com/atom/atom/issues/4966 remains open and packages `metrics` and `exception-reporting` are still enabled by default.
* metrics: sends personal data to Google Analytics
* exception-reporting: sends personal data to bugsnag.com
* metrics: sends personal data to Google Analytics
* exception-reporting: sends personal data to bugsnag.com
Thank you for the heads up - I've been using Atom for 6 months and did not know they had these enabled.
The good part about using an open source editor is that you can disable (and know about them) these packages if you don't want to be tracked.
Yes, but you first have to know about it.
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!
[1] https://discuss.atom.io/t/visual-studio-code-and-atom/16479/... [2] https://en.wikipedia.org/wiki/Electron_(software_framework) [3] https://forum.sublimetext.com/t/sublimes-future-and-open-sou...
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!
[1] https://discuss.atom.io/t/visual-studio-code-and-atom/16479/... [2] https://en.wikipedia.org/wiki/Electron_(software_framework) [3] https://forum.sublimetext.com/t/sublimes-future-and-open-sou...
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.
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.
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.
[1] https://github.com/syohex/emacs-helm-ag
[1] https://github.com/syohex/emacs-helm-ag
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.
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.
Do you know how instant search is implemented? I'd assume the files are pre indexed but I'm wondering how large projects are handled.
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).
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.
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.
Yeah atom has always had issues with files over a few kb that are all on the same line.
If the file doesn't have any crazy long lines, i've had it handle 5mb+ files with no issues.
If the file doesn't have any crazy long lines, i've had it handle 5mb+ files with no issues.
"i've had it handle 5mb+ files with no issues."
Wow! It's so exciting living in the 1990s!
Wow! It's so exciting living in the 1990s!
Okay, if you want to be a dick about it.
I've had it handle 5GB+ files with no issues.
I've got a 6.3gb log file open in it right now.
I've had it handle 5GB+ files with no issues.
I've got a 6.3gb log file open in it right now.
Try doing a find/replace/syntax highlight/multiple cursor/anything productive. Actually don't, your computer will explode!
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!
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.
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 agree 100%
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.
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.
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.
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.
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.
What do you use Emacs for? Atom?
What do you use Emacs for? Atom?
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.
Not a day 1 user of atom, but similarly I've been using textmate for huge files (or really quick edits). It's a nice one-two combo.
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.
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.
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.
Are you implying Sublime Text is somehow on its way "out"? Is there a reliable way to compare text editor usage beyond popularity from Google Trends?
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.
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.
It's actually just one guy behind Sublime. Probably the reason why it is sinking.
Developing software like ST alone is actually pretty amazing.
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?
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?
While I do like Sublime Text, development really has stagnated and it doesn't help that the core is closed source.
There hasn't been a new dev build of Sublime Text 3 in six months. It doesn't look very active, and being closed source definitely doesn't help.
Yes, many nice features are missing.
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.
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.
Depends what kind of things you need/want to make. I've modified few themes and it's pretty simple stuff after little experimentation.
Ummm.
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.
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.
You don'd have to code your themes, there are always tools like ThemeCreator: https://github.com/mswift42/themecreator. (Works for Emacs and Atom)
> I mean, you have to code your themes
Are you talking about themes in Emacs? Because if so, that statement is definitely not correct.
You can code your themes (and sometimes I do!), but it's definitely not the standard or only way of doing it.
If you're talking about Atom... Thanks for the info :)
Are you talking about themes in Emacs? Because if so, that statement is definitely not correct.
You can code your themes (and sometimes I do!), but it's definitely not the standard or only way of doing it.
If you're talking about Atom... Thanks for the info :)
You can style it using CSS. How much easier could it be?
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.
He may be thinking about that?
He may be thinking about that?
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.
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
https://github.com/MarcoPolo/atom-paredit
I'd also recommend looking at the atom api docs, if you really want to switch.
I'd also recommend looking at the atom api docs, if you really want to switch.
Thank you, this looks like a great minimal yet complete plugin. I'll have to try and hack my own together this weekend.
You're welcome :-D.
I'd recommend sticking with emacs though. CLJS is a better lisp than elisp, but emacs is a better platform than atom.
I'd recommend sticking with emacs though. CLJS is a better lisp than elisp, but emacs is a better platform than atom.
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
I liked the design of Atom, but for this reason, I guess it's not the time for me to give up Emacs yet
Been using sublime, code and atom. Atom seems to freak out in unexpected ways and has the downside of spewing tose node.js errors.
Code and sublime just seem more solid. I don't need explosions in my editor when I'm focused.
Code and sublime just seem more solid. I don't need explosions in my editor when I'm focused.
not calling anyone a liar, consider it an anecdote, but i've used Atom exclusively for over a year and it performs great.
If you like vim and spacemacs, give proton-mode a shot: https://atom.io/packages/proton-mode
If you're thinking on taking the plunge from Sublime Text, here are some setup notes aimed at web developers: http://www.developingandstuff.com/2015/04/setting-up-atom-fo...
Haven't tried Atom for about one and half years; at that time it was a performance trainwreck. Is it better?
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.
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.
> Is it better?
Absolutely, yes.
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.
Absolutely, yes.
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.
I've been using it as my main editor for a couple years now, and yes, it's getting better with every release.
Yes, it is quite a lot better. I just restarted using after two years pause.
Now I find that I open half my sessions in Atom, half in sublime.
Now I find that I open half my sessions in Atom, half in sublime.
I use Sublime Text 3 90% of the time and GVim the rest. I don't have any complaints about either editor.
What are the primary reasons that drive people to Atom (or Visual Studio Code for that matter)? Is there some great feature that I'm missing out on?
What are the primary reasons that drive people to Atom (or Visual Studio Code for that matter)? Is there some great feature that I'm missing out on?
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.
That appears to be one of the changes in 1.4.0:
https://github.com/atom/atom/pull/9968
https://github.com/atom/atom/pull/9968
I've simply used https://github.com/mpeterson2/save-session.
Looks like they added just that on this release:
>Untitled documents in a project are now serialized and restored.
>Untitled documents in a project are now serialized and restored.
Probably. It has been preserving my sessions for a while.
> 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.
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.
The runtime architecture is a bit bloated IMHO.
Still can't use it for reviewing a commit (git commit -va) kills my MBPr.
But glad things are moving forward. Still haven't decided between Atom and Sublime though..
But glad things are moving forward. Still haven't decided between Atom and Sublime though..
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.
Well, ST has been around little longer, so there is still time for Atom to catch up.
It has fundamentally hugely more overhead than ST so really doesn't have a chance in the speed stakes.
[deleted](1)
It's not technically possible for Atom to catchup with SublimeText in terms of speed, unless their is a big leap in quantum computing.
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!
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
Just a heads up, i really liked swackets, but it ended up wreaking havoc with atom.
It was slow, it messed with tern-js a bit, and the brackets would "pop" into the viewport whenever i scrolled.
That was about a month ago so it may be better now.
It was slow, it messed with tern-js a bit, and the brackets would "pop" into the viewport whenever i scrolled.
That was about a month ago so it may be better now.
I have the same issue. I think it's because of changes on the autocomplete settings, but I can't pinpoint it.
Have you had any lock? It's annoying as hell as there is no close button either.
Have you had any lock? It's annoying as hell as there is no close button either.
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?
Python was updated from 2 to 3 among other things
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?
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?
The features do not outweigh the performance loss in my experience.
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.
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.
When I tried it last time, maybe a year ago, I was quickly turned off by how uncustomisable it was, despite the claims.
All I wanted was a non-blinking block cursor ...
Now I just found this https://github.com/olmokramer/atom-block-cursor
But more than 200 commits to support non-blinking block cursors? I think Atom is not for me.
All I wanted was a non-blinking block cursor ...
Now I just found this https://github.com/olmokramer/atom-block-cursor
But more than 200 commits to support non-blinking block cursors? I think Atom is not for me.
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.
It's not a good metric. Instead look at the 278 lines of code necessary to achieve it.
You really can't please some people.
:)
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.
That's what happens when someone tries to write desktop application in JS :)
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
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
Are you sure its not just other peoples experience that doesn't match yours rather than FUD?
Are you sure its not FUD?
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 really shitty machines. Its very hard for me to accept that all this complaining about its performance is not FUD.
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 really shitty 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.
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.
It runs badly on my 8gb 2013 MacBook Air, on a medium sized php+javascript project.
I've been trying Atom every 3 months since it came out. Just a few plugins and Linting and is still very slow and I hate lag while typing.
I don't have this problem with Sublime, for example, where typing is instant. Even eclipse and Android studio are more responsive when typing.
I've been trying Atom every 3 months since it came out. Just a few plugins and Linting and is still very slow and I hate lag while typing.
I don't have this problem with Sublime, for example, where typing is instant. Even eclipse and Android studio are more responsive when typing.
It runs badly on my 16GB, i5 2500k desktop. Windows & Debian. 1GB RAM usage and a full CPU core is not acceptable for a text editor.
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
Happy to see highlighted JSCAD [0]
Does anyone find JSCAD modeling inside Atom useful?
Tips/suggestions? I've been working on this project [1]
[0] https://github.com/github/linguist/pull/2712
[1] https://atom.io/packages/atom-scad-preview
Does anyone find JSCAD modeling inside Atom useful?
Tips/suggestions? I've been working on this project [1]
[0] https://github.com/github/linguist/pull/2712
[1] https://atom.io/packages/atom-scad-preview
Atom seems pretty nice these days, but why would a competent emacs user switch to atom?
Why would a spacemacs user switch to atom? Does it have any advantages?
Why would a spacemacs user switch to atom? Does it have any advantages?
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.
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 anyone know of a good Python completion plugin for Atom similar to what PyCharm has (i.e. can complete models stuff etc)?
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.
Atom 1.3 was hang up when opening same file name.
1.4 seems to fix this issue.
https://github.com/atom/atom/issues/10060
I submitted a PR for homebrew's cask once I read about the update.
https://github.com/caskroom/homebrew-cask/pull/17022
https://github.com/caskroom/homebrew-cask/pull/17022
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.
Best thing about some of the modern tools like Atom is that, by the time you know about the release, you are already updated!
[deleted]
But it's still so slow.
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