Atom 1.2(blog.atom.io)
blog.atom.io
Atom 1.2
http://blog.atom.io/2015/11/12/atom-1-2.html
58 comments
You could probably use vim inside atom through neovim and this project: https://github.com/carlosdcastillo/vim-mode
I haven't personally tried it yet, but something like this will certainly be a good option in the future.
I haven't personally tried it yet, but something like this will certainly be a good option in the future.
Doesn't give you the whole suite of vim keys but for average vim users this should be okay. Saying this from experience.
It does give you all the suite of vim keys (or it should). It uses neovim's API to connect to neovim. You can even use (neo)vim's plugins because the commands are processed by neovim, not by Atom. In other words, the plugin acts as an interface between neovim and Atom; thus, everything you have in neovim you have it in Atom.
I dream of the day someone shows me a text editor I can be more efficient in than Vim. With a ~30 line .vimrc I can work on the vast majority of the machines on this planet without any trouble; the appeal of editors like Sublime and Atom simply baffle me.
For context, I was a sublime user until about 2 years ago, and prior to that I worked in Notepad++.
However, I rarely work outside of a terminal. So this definitely guarantees a clear bias.
For context, I was a sublime user until about 2 years ago, and prior to that I worked in Notepad++.
However, I rarely work outside of a terminal. So this definitely guarantees a clear bias.
Spacemacs (or even just evil mode) for Emacs. I was a Vim user too for about five years and then I discovered Spacemacs and eventually converted to Emacs keybinds and haven't looked back. The elegance of Emacs is just very hard to surpass.
+1 for Spacemacs, you don't have to discover all different mode for Emacs, just enable corresponding "layers".
I use atom-vim as well as the full suite of extremely flexible key-bindings and I am FAR faster in Atom then I was in native vim. Not only that, but the plugin ecosystem is more suitable for my needs, more hackable, and more modern. As a JavaScript developer, Atom has totally recharged my workflow.
One thing that does need some love is tree-view; I sorely miss the full functionality of NERDTree (paging, text search, etc)
One thing that does need some love is tree-view; I sorely miss the full functionality of NERDTree (paging, text search, etc)
Why do you feel faster using Atom with atom-vim than native vim?
In contrast, it baffles me that some don't understand the draw—even if not personally appealing—of editors like Sublime or Atom.
And I say this as an emacs evil user.
And I say this as an emacs evil user.
Sublime and Atom might be the next best options after vim for people not willing to learn vim. I use vim, I really like it, but I understand a lot of people might not care too much about it, and both of the mentioned editors are very good.
Have you tried doing iOS development? That would suck without XCode (even though XCode itself sucks)
Why doesn't anyone create a viable, open source XCode alternative? Are all the libraries proprietary?
JetBrains has an IDE called AppCode, an alternative to Xcode (not open source). But it still relies on Xcode for distribution and the UI designer, and it lags far behind the update cycle of Xcode. And that is a commercial company with steady revenue dedicated to making IDE. Imagine the difficulty of an open source alternative.
Honestly, if you were willing to rely on the undocumented SourceKit API then you wouldn't have nearly this many problems.
You are not allowed to link binary not compiled by XCode to iOS/osx ecosystem.
1. It's really hard and 2. mostly
The vast majority of my work has been in open source languages using open source tools. So my experience with xcode is very limited and I imagine your thoughts to be something that may change my tune if I were to be in that ecosystem.
I really enjoy typescript and I really enjoy the cutting edge features. Atom editor is the only editor that has the typescript plugin that works with the latest features of typescript. I hate the performance of atom but it is worth the tooling.
how does it compare to visual studio code?[0] for TS development?
[0] https://code.visualstudio.com/
[0] https://code.visualstudio.com/
I use them both back and forth for a current TS project, and I think both are very good.
I think the Atom plugin is a little bit better in the "help you and show errors as you type" department. With VS code I have configured a gulp compile and VS Code Task with problem matcher configuration, but that is a little bit slower than the Atom plugins compile/build on save configuration and sometimes doesn't show errors on the correct place. But that might be my configuration, so it could be better than I think.
What Atom also supports and VS Code not is the glob expressions for included files in tsconfig.json.
However most of the time I'm currently preferring VS Code, because the editor is just much more responsive (although Atom got better with the 1.1 update).
Another important thing is that VS code supports node.js debugging (with js and ts), which is really helpful.
I think the Atom plugin is a little bit better in the "help you and show errors as you type" department. With VS code I have configured a gulp compile and VS Code Task with problem matcher configuration, but that is a little bit slower than the Atom plugins compile/build on save configuration and sometimes doesn't show errors on the correct place. But that might be my configuration, so it could be better than I think.
What Atom also supports and VS Code not is the glob expressions for included files in tsconfig.json.
However most of the time I'm currently preferring VS Code, because the editor is just much more responsive (although Atom got better with the 1.1 update).
Another important thing is that VS code supports node.js debugging (with js and ts), which is really helpful.
Does the typescript auto completion component of Atom the same as in VSCode ?
Maybe tell us what programming languages do you work with.
Elixir, Ruby, JS, and Python.
[deleted]
Another POV here, I moved from Visual Studio after using it for over 15 years. For me, Atom is fucking fast. Lack of UML diagramming, database designer and TFS integration is a blessing in disguise.
I love Atom. I've been using it since the day it was announced. But I don't use it for the speed. It still chokes on huge files. When I need to open something big, I reach for Sublime, and it handles it with ease.
Why do you prefer Atom over Sublime Text (except when you need to open a big file)?
I have a Lenovo X1 Carbon - no slouch by any measure, but Atom is noticibly slower to open documents and start up than Visual Studio 2015.
I'm was still on 2013 and my install is almost 2 years old. VS seems to get slower over time. And this is without powertools or resharper. Maybe it is just me but Atom sure feels quicker.
> Atom is fucking fast
Speed is relative. Faster than what editor ?
Speed is relative. Faster than what editor ?
Visual Studio?
I use both.
Visual Studio in a virtual machine via Parallels and Atom as a native OSX app. I find that VS is still faster.
I was referring to the person asking what Atom was fast relative to.
I've been meaning to give atom a months worth of working with but am not sure if it's worth moving over to from emacs. I do like how simple its packaging system is. Any major complaints from users?
It's still unbelievably slow. That's why I still use Emacs and occasionally Sublime Text for things like HTML.
That's odd. I am replying here, although there are a number of atom-is-slow comments throughout the thread. I don't find it to be slow with normal-sized sourcefiles. By "normal", I mean less than, say 5kb of text per file. Big files I do avoid in atom, but they tend to be rare in my codebases.
I don't use a ton of plugins, just tag matchers, minimal, and linters. I do all my build tooling (gulp for js/web dev, mavensmate for salesforce, etc) outside of atom, so maybe that helps.
Of course, the only real benefit I feel over sublimetext is in plugins. Linter support in atom is (IMO) better than ST. For actual code editing, they're all similar enough once you learn key bindings and whatnot.
I will say: being proficient in vi means I can work on ARM devices (Chromebooks with crouton), because neither ST nor atom work on arm. Yet, from the atom perspective, or ever from the ST one, which is the other reason I like the atom project. Loftier, FOSS goals.
I don't use a ton of plugins, just tag matchers, minimal, and linters. I do all my build tooling (gulp for js/web dev, mavensmate for salesforce, etc) outside of atom, so maybe that helps.
Of course, the only real benefit I feel over sublimetext is in plugins. Linter support in atom is (IMO) better than ST. For actual code editing, they're all similar enough once you learn key bindings and whatnot.
I will say: being proficient in vi means I can work on ARM devices (Chromebooks with crouton), because neither ST nor atom work on arm. Yet, from the atom perspective, or ever from the ST one, which is the other reason I like the atom project. Loftier, FOSS goals.
>I don't find it to be slow with normal-sized sourcefiles. By "normal", I mean less than, say 5kb of text per file.
5 thousand bytes is pretty small. It is 122 lines of text if we use the average bytes per line of some code I have lying around (Emacs Lisp, exactly one byte per character, lines limited to 80 characters). For comparison, the average lines per file in the code I have lying around is 233.
5 thousand bytes is pretty small. It is 122 lines of text if we use the average bytes per line of some code I have lying around (Emacs Lisp, exactly one byte per character, lines limited to 80 characters). For comparison, the average lines per file in the code I have lying around is 233.
> It's still unbelievably slow
When was the last time you tried it? It is plenty fast for me now. Original load times were 7 to 10 secs and are now under 2 secs for me, with a zillion packages to load.
When was the last time you tried it? It is plenty fast for me now. Original load times were 7 to 10 secs and are now under 2 secs for me, with a zillion packages to load.
Oh, I open it up about once a week. It's not that much slower than, say, Sublime Text, without any plugins installed. However, I like to load up my text editors with IDE-like affordances. I also wanted to experiment with a bunch of Facebook languages so I thought I'd try Nuclide, which basically made Atom unusable that last time I tested it.
It's a shame that it doesn't work better, because it's truly a great idea. I have some faith that the performance will improve but there is a limit and I'm almost certain that that limit is below that of editors that render natively. Now, if they started supporting a statically typed JS like TypeScript or if they did something like restrict the plugin architecture to a simpler DSL and the theming language to be a smaller subset of HTML, that might improve things, but it would also no longer "just work" for web developers wanting to write plugins for it.
Edit: Also if WebAssembly becomes a widespread thing it would help performance greatly.
It's a shame that it doesn't work better, because it's truly a great idea. I have some faith that the performance will improve but there is a limit and I'm almost certain that that limit is below that of editors that render natively. Now, if they started supporting a statically typed JS like TypeScript or if they did something like restrict the plugin architecture to a simpler DSL and the theming language to be a smaller subset of HTML, that might improve things, but it would also no longer "just work" for web developers wanting to write plugins for it.
Edit: Also if WebAssembly becomes a widespread thing it would help performance greatly.
> I thought I'd try Nuclide, which basically made Atom unusable that last time I tested it.
I found the same. I just tried nuclide again, which I do once a month or so, and it basically rendered Atom useless.
> I have some faith that the performance will improve but there is a limit
I used to argue the same thing, because it is built on the DOM, but after talking to a few of the Atom developers and a guy from Google at a conference I have new hope. The google guy said in a talk that Google was adding an API that allows javascript to go around the DOM. You will be able to render text into an existing DIV directly without triggering the DOM. This was specifically to allow things like atom to display and scroll text fast.
So there are clever people working to fix speed problems. I personally am not seeing speed problems even with 30 or 40 plugins. I think the breaking point was 1.0.
I found the same. I just tried nuclide again, which I do once a month or so, and it basically rendered Atom useless.
> I have some faith that the performance will improve but there is a limit
I used to argue the same thing, because it is built on the DOM, but after talking to a few of the Atom developers and a guy from Google at a conference I have new hope. The google guy said in a talk that Google was adding an API that allows javascript to go around the DOM. You will be able to render text into an existing DIV directly without triggering the DOM. This was specifically to allow things like atom to display and scroll text fast.
So there are clever people working to fix speed problems. I personally am not seeing speed problems even with 30 or 40 plugins. I think the breaking point was 1.0.
+1. I normally work on small-ish codebases, and even then Atom just feels sluggish. It's performance with large files is laughable - normally just crashes/stalls - and the nicer ui does not make up for it. Adding plugins to make the development experience great for my workflow just ends up slowing it down :(
I like to try it every so often but end up going back to Sublime Text 2.
I like to try it every so often but end up going back to Sublime Text 2.
That's a shame, it's really aesthetically pleasing. But beauty alone can't beat ol' reliable!
Plugins are very brittle and hard to read - courtesy of coffescript/javascript - constant 'undefined' error popups and the likes - given up on trying to fix/report as it seems to be a whack-a-mole just using it as a basic text editor and removed all fancy plugins.
Very slow search with large files, rendering performance not the best but tolerable.
On Windows it doesn't let me enter ']}' characters because of my keybord layout conflicting withing with shortcuts (can't tell if this is still the case it was in 1.0 - I haven't used Windows in a while)
I use it for editing python scripts/resource definition YAML files in my asset pipeline and since it mostly comes down to file organization having an actual tree view view where you can cut/paste files and visualize the structure with nice icons beats ASCII art from NERDtree. Also QtCreator project structure with CMake is immutable so I use it to move organize C++ source files as well. It works as a treeview + texteditor and it integrates with git - that's good enough for what I need.
Very slow search with large files, rendering performance not the best but tolerable.
On Windows it doesn't let me enter ']}' characters because of my keybord layout conflicting withing with shortcuts (can't tell if this is still the case it was in 1.0 - I haven't used Windows in a while)
I use it for editing python scripts/resource definition YAML files in my asset pipeline and since it mostly comes down to file organization having an actual tree view view where you can cut/paste files and visualize the structure with nice icons beats ASCII art from NERDtree. Also QtCreator project structure with CMake is immutable so I use it to move organize C++ source files as well. It works as a treeview + texteditor and it integrates with git - that's good enough for what I need.
"courtesy of coffescript/javascript" ... I wonder if switching to TypeScript for most development would help.
Although I'm a huge statically-typed language fan, I suspect it would not. I don't think the language is really the problem here. I think it's more that the environment is young. It will take time for the higher quality plugins to supplant the lower quality ones.
You can see the same thing with Node modules. The quality of the main modules that people use has gone up over the last 2 years or so, IMHO. This is not because the modules have gotten better, but rather that people have switched to the better modules over time.
This year I wrote a lot of coffeescript code. I really like it. I don't think it is harder to write good code in it than any other language. I think the main problem is that it is more accessible than some other languages and so attracts relatively novice programmers.
Having said that, TypeScript has been on my TODO list of languages to try for ages and I haven't actually written any code in it. I'm mostly saying that I don't expect strong typing to magically fix the problems with poor plugins. People will just find different ways to make mistakes ;-)
You can see the same thing with Node modules. The quality of the main modules that people use has gone up over the last 2 years or so, IMHO. This is not because the modules have gotten better, but rather that people have switched to the better modules over time.
This year I wrote a lot of coffeescript code. I really like it. I don't think it is harder to write good code in it than any other language. I think the main problem is that it is more accessible than some other languages and so attracts relatively novice programmers.
Having said that, TypeScript has been on my TODO list of languages to try for ages and I haven't actually written any code in it. I'm mostly saying that I don't expect strong typing to magically fix the problems with poor plugins. People will just find different ways to make mistakes ;-)
>Although I'm a huge statically-typed language fan, I suspect it would not.
Most of the bugs I've dealt with would be fixed by static typing (undefined property use, recursive dependancies, etc.) and it would give more structure to the plugins + make the API self documenting and toolable which would make it easier to drop in and fix the issues
Most of the bugs I've dealt with would be fixed by static typing (undefined property use, recursive dependancies, etc.) and it would give more structure to the plugins + make the API self documenting and toolable which would make it easier to drop in and fix the issues
Just speed. Still can't keep up with the other major players.
I like that it's open source, but I couldn't bring myself to contribute because it's all Coffee. That's more of a personal gripe, though.
I like that it's open source, but I couldn't bring myself to contribute because it's all Coffee. That's more of a personal gripe, though.
> Any major complaints from users?
AltGr is still broken. The problem has been known for almost 2 years and there are about a hundred duplicates.
https://github.com/atom/atom-keymap/issues/35
If you aren't using an US keyboard layout, this might be a problem.
AltGr is still broken. The problem has been known for almost 2 years and there are about a hundred duplicates.
https://github.com/atom/atom-keymap/issues/35
If you aren't using an US keyboard layout, this might be a problem.
First time I hear an emacs user saying so lightly that he wants to move to something else, how well do you know emacs?
Echoing others, I've been using emacs for close to 10 years now. I've been keeping a close eye on Atom because it's the firs time I've seen a editor start to gain popular appeal that can approach the customizability and power of Emacs.
The other thing holding it back is performance. It might be something that Atom can never be "good enough" at, but I have hopes, if only with increases in compute speed.
The other thing holding it back is performance. It might be something that Atom can never be "good enough" at, but I have hopes, if only with increases in compute speed.
I've used Emacs for the last 23 years. Although Emacs has some strong points, I'm looking to switch, maybe to Atom.
(It sounds a little like you think that the only reason everyone doesn't use Emacs is the steepness of the initial learning curve.)
(It sounds a little like you think that the only reason everyone doesn't use Emacs is the steepness of the initial learning curve.)
Not really, is just that emacs is such a powerful programming environment that it's strange to see someone that knows it, leaving it, because the alternatives doesn't really offer much in return IMO.
I left Emacs for Sublime a few years ago, after almost 20 years of Emacs. Sublime isn't the greatest in feeling native to the platform, but it does better than Emacs. I prefer to spend my time on my projects instead of the editor itself.
i've been only using emacs for about three years. Don't get me wrong it's the great. I'll never truly let go of it as i use it everyday just for org-mode itself. But i always wonder how other text editors are doing, especially an up and coming one like atom.
Atom 1.2 is just two weeks from 1.1 (released on October 29). That was fast :)
[deleted]
Hold on, let me just update my GPU driver so I can run my text editor
I don't know if I will leave Vim for Atom, but its certainly a great tool. If some newbie asks my opinion on what editor/ide to use, I will be inclined to say Atom as its so easy to get started with.
PS> And seems like they finally fixed the hidpi issues with this release!