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 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
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 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.
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.
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.
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.
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.
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'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.
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 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.
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'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.
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.
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?
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.
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.
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 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.
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.
> 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'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.
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.
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.
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.
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'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.
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.
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 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).
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
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?
203 comments
[ 3.2 ms ] story [ 260 ms ] threadBut glad things are moving forward. Still haven't decided between Atom and Sublime though..
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!
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.
Have you had any lock? It's annoying as hell as there is no close button either.
Now I find that I open half my sessions in Atom, half in sublime.
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.
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.
>Untitled documents in a project are now serialized and restored.
https://github.com/atom/atom/pull/9968
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?
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).
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.
If the file doesn't have any crazy long lines, i've had it handle 5mb+ files with no issues.
Wow! It's so exciting living in the 1990s!
I've had it handle 5GB+ files with no issues.
I've got a 6.3gb log file open in it right now.
It did take about 2 seconds to load the file though, so you can make fun of that!
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.
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 do you use Emacs for? Atom?
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.
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.
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.
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.
He may be thinking about that?
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 :)
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.
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?
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.
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.
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
I liked the design of Atom, but for this reason, I guess it's not the time for me to give up Emacs yet
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.
It's not a good metric. Instead look at the 278 lines of code necessary to achieve it.
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.
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...
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.
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.
[1] https://github.com/syohex/emacs-helm-ag
Looks like Emacs helm uses Silver Searcher which is real time, but impressively fast.
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.
Have they switched from Coffeescript to JavaScript?
Kind of curious why they made that decision in the first place.
Oh, they are a Ruby shop. Right.
"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
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
- 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.
Why would a spacemacs user switch to atom? Does it have any advantages?
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.
* metrics: sends personal data to Google Analytics
* exception-reporting: sends personal data to bugsnag.com
https://github.com/caskroom/homebrew-cask/pull/17022
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.
I'd also recommend looking at the atom api docs, if you really want to switch.
I'd recommend sticking with emacs though. CLJS is a better lisp than elisp, but emacs is a better platform than atom.
Code and sublime just seem more solid. I don't need explosions in my editor when I'm focused.
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?