Atom review

Introduction

Atom is a new text editor based on web technologies. Since it’s initial release in 2014, it has gathered momentum with many developers, according to a stackoverflow survey in 2016 it is ranking as the 9th most popular development environment.

Atom is based on electron, and is written in CoffeeScript. This gives Atom the benefits of a native app while having access to the GUI elements from the web.

Its development is mainly supported by GitHub and Facebook. Facebook is developing a set of plugins for Atom that makes up the Nuclide IDE and is also contributing a bit to the main project. While GitHub is leading the Atom core project.

In this review, I will discuss Atom usage from the perspective of a C/C++ developer and its potential as a platform to contribute to.

A few notes before we start, some of this review is more a personal account of my experience of trying Atom as a C/C++ developer working on GDB.

So I think some introductions are in order.

I usually use Emacs to do my work, and Atom is in many ways very similar to Emacs, so you will hear me compare it to Emacs in this review, don’t be scared by it. I will also compare it to the Eclipse IDE since this is used by many.

The main reason I’m doing this besides my personal experience is that Emacs in terms of features and maturity is way ahead of Atom. So comparing it to Emacs a bit helps to understand how much work is left to be done in Atom or if their design is good enough for the future.

Also, GDB is an old GNU project, with some special coding styles and it’s also quite large, so depending on the project you may not hit some of the issues I encountered.

So let’s start, 1st up:

Community

So who is developing Atom, who is using it ?

So here it’s important to understand that there is Atom and then there’s the Atom plugins.

Since a lot of the functionality of Atom is in it’s plugins it’s hard to tell the exact size of the community and who is involved by looking only at the Atom core editor.

Contributors

Facebook is quite involved in it’s Nuclide IDE based on Atom.

Looking at the Facebook opensource projects we can see that there’s only 1 IDE: https://code.facebook.com/projects/web/ide

And it’s Nuclide based on Atom.

So I think it’s safe to say that Facebook is a big contributor to Atom.

There’s also http://platformio.org/platformio-ide Platform-io makes a C/C++ embedded development IDE !

So making an IDE from atom is a demonstrated thing even for C/C++ embedded development.

In the git stats of the main project (c.f. https://www.kayaksoft.com/git_stats/atom/authors.html)

We can see that GitHub contributes 70% of the commits, while 20% seems from independent developers and 1% from Facebook.

I think this makes atom quite diverse with 20% of independents, compared to Emacs for example a much older and diverse project in emacs around 50% are of gnu.org and the rest are independents. See https://www.kayaksoft.com/git_stats/emacs/authors.html)

So starting off with 20% is not bad. Compared with VSCode MS is responsible for 75% of the commits with 18% independents see: https://www.kayaksoft.com/git_stats/vscode/authors.html

Users

Atom seems to be quite popular making it to the 9th place in the StackOverflow survey (http://stackoverflow.com/research/developer-survey-2016#technology-trending-tech-on-stack-overflow-losers)

That’s before Xcode, but bellow Eclipse, VS Code was not rated yet.

We can see in google trends that Atom is quite popular, and compared to VS Code they are both as popular with users: https://www.google.com/trends/explore?q=atom editor,vscode

Both editors are so new however that there is no clear trend there other that they are gaining traction with users.

Based on the level of plugin development for C/C++ however I don’t think there’s that many users working with C/C++, most users seem to be doing JavaScript,CSS,HTML etc

Plugins

We can see at https://atom.io/packages that atom features 5557 plugins at the moment. And that 7,414 packages & themes have been downloaded 77,031,400 times.

Which gives an idea of the user base size and plugin development size.

To give some perspective VS Code has 2208 extensions in its store.

And Emacs melpa archive has 3,464 Packages 37,770,804 downloads to date.

So Atom fares even higher than Emacs, in terms of plugins and downloads, and higher then VS Code.

Plugins are very diverse and their integration with github is very nice, access to the source and plugin issues etc with github directly makes it easy to contribute or find information about a plugin.

Contributing

In https://github.com/atom/atom/blob/master/CONTRIBUTING.md we can see that they have a process for taking design decisions:

“When we make a significant decision in how we maintain the project and what we can or cannot support, we will document it in the atom/design-decisions repository. If you have a question around how we do things, check to see if it is documented there. If it is not documented there, please open a new topic on Discuss, the official Atom message board and ask your question.”

So it’s nice that even for core decisions they consider the community.

Their discussion platforms on slack and discuss is quite open too.

You do get a feeling that this is really a community project.

Licensing

https://github.com/atom/atom/blob/master/LICENSE.md

Atom is licensed under an MIT license, which basically is you can do whatever you want with the code.

Also Atom is not dual licensed like VS Code.

So I would say there’s absolutely no licensing issue with Atom.

General concepts you should know about.

So Atom is new, it’s based on web technologies but compared to the Eclipse IDE for example it has some concept changes you need to know about.

First up, Atom is by itself just an editor, it’s not an IDE. So you will be able to edit code and that’s it without any plugins installed.

Plugins

That makes Atom a base on which any developer may create its own IDE like environment. If you want to compile C++ code with it, you install a builder plugin, if you want to navigate your code you install a tags plugin etc… So it ends up that Atom is what YOU make it to be.

Plugins are an essential part of Atom and I found that many aspects of the plugins and their management is quite well done on Atom for example: there’s proper dependency management, if you have a problem with a plugin the warnings are clearly indicated, if the plugin crashes there’s a way to submit the problem easily and see if that problem was encountered before.

While the Atom core seems a good platform for plugins, plugins themselves however can vary greatly in quality. Plugin discovery is not always easy as the most downloaded plugin is not always the best one, and one must resort to some research on the web etc to figure out what to use exactly.

Once the right initial plugin combination is found however it’s easier to follow and update or change plugin.

Configuration

So all these plugins come with minimal defaults, you will need to configure them.

This is a very interesting concept in Atom, rather than having menu after menu after wizard to configure things you just have a plain text file with json like data (cson) that is the configuration of Atom and it’s plugins.

So all your config is in 3-4 config files and to change the config you just change these files.

Note that Atom also has a menu to configure plugins but it’s just a helper to write those files properly. It does come in handy however to see what is available from a plugin etc.

While the cson config files are static you can do dynamic configuration in the init script written in coffeescript.

Note that this is the way to configure keybindings also or anything else.

The command palette

This is by far the most interesting concept change from IDEs like Eclipse. If you want to do something like let’s say, compile your code, where in eclipse you would search for the compilation icon, or search the command in a menu, in Atom you can pop-up the command palette and just type Build.

The command palette is like a search box for any Atom function exposed to the user. So if there’s anything you want to do in the editor you don’t search for a menu or a icon you just type what you want and it will find it. It will also show the keyboard shortcut for the command, so that you can learn shortcuts for the commands you use frequently.

This compares with the M-x command in Emacs and works pretty much the same way. Atom’s version is visually more appealing are you don’t get the keybindings by default in Emacs.

So the command palette is in my view an excellent feature. It removes the needs for menus and icons that take up screen real estate and that you need to visually search for, it provides easy searchable discovery of the editor features, and it helps to memorize the keybindings.

Panes

This is a major feature compared to Eclipse and very much like emacs, you can split the editor window any way you want, vertically or horizontally any number of times with simple keybindings.

However not everything is a pane, so unlike emacs where everything is an emacs text buffer that you can search in or apply your normal keybindings in atom not everything is a pane, so for example you can’t search in the errors window displayed by the linter. Nor can you open this window like you would another text buffer.

This is really too bad as it forces windows that are not panes to implement things like search etc themselves, and provides an inconsistent command interface to the user.

Using it as a C/C++ developer.

Installation

I found installation to be very easy, just downloading and installing a .deb worked fine.

Installation from source is also easy and has very few dependencies.

For plugins, just click install and it’s done and enabled.

However package dependencies are not always managed, you may need to install some dependencies manually. There is dependency management in the Atom core but some plugins don’t make use of it.

You may also need external libraries (not in node JS) or program as dependencies, these are not managed by Atom. Understandably since Atom has no knowledge of the distro or OS it’s on.

So overall the installation is simple and efficient.

Indentation

This can be problematic, support for indentation is very basic providing minimal options mostly your choice of tab or spaces and the number of spaces.

Auto indentation can fail too for example:

This fails:

if (foo)
bar ()

it works with:
if (foo) {
  bar ()
}

Documentation of the auto indentation logic is also non-existent, you will have to read the code.

I was also unable to configure something like GNU style indentation required by GDB where 8 spaces are replaced by a tab and the indentation level is 2 spaces.

So that made it a huge problem to develop GDB in Atom.

Compared to Emacs where you can configure everything about indentation and that has GNU style indent by default and proper documentation, this still has ways to go.

Code navigation

This is well supported in Atom with the help of tags with the atom-ctags plugins you can navigate function definitions easily. Finding a symbol can be slow however you can see the CPU go to 100% and the display lagging a bit.

Seems like performance needs to be improved in that area but that it’s on the right path.

Also a feature missing is a way to navigate in a stacked way, like going inside a definition, again, again and then going back and back… Atom with atom-ctags only supports going in and coming back once. But I’m guessing this could be an easy improvement.

Also worthy of note is the support for bookmarks as I like that feature very much Atom does let you set a bookmark in some code and navigate your bookmarks easily.

Auto-complete

Autocomplete with autocomplete-clang works quite well and is almost as good as the emacs one, the arguments completion is lacking sometimes however as you will get the 1st argument but not the others.

Still it’s quite usable.

Linter

Getting the linter to work with linter-gcc is not easy with the GDB project, trying to make this work was not easy as it turns out that debugging a plugin can be hard.

At least for a non JS dev like me, going into the inspector to figure out the problem in the plugin was non-trivial.

This plugin could be improved with better ways to debug what is going on and fix the include paths etc.. like is done in emacs with the flycheck-compile command.

I ended up using emacs flycheck-compile to figure out the proper config for Atom.

But even with that I could not get it to work properly. I would need to take more time to do it.

With a simpler project it works however.

Version control (git)

I did not spend that much time on git interaction with atom, it looks OK but some features may be missing see:

https://github.com/atom/language-git https://github.com/atom/git-diff

More experimentation is needed on that subject.

Debugging

There is https://github.com/xndcn/atom-debugger (15 commits in total over a few months last year)

But it’s very very alpha and only supports the most basic functions like: staring a program, setting breakpoints and stepping.

Anything else like inspecting variables/memory is not done.

No console support either…

We could say that debug support for C/C++ is in infancy or non-existent.

Building

I found this plugin: https://atombuild.github.io/

This works if you have a top level Makefile, you will be able to compile, see errors and navigate to them using the linter package.

Other configurations like out of tree builds require manual configuration.

But at least the building blocks are there.

Console

With: https://github.com/platformio/platformio-atom-ide-terminal

The console is pretty well supported, you can even map a term to a file or folder.

The terminal however is not considered as a pane, so you can’t split term windows or manage them like you do files.

You can’t search for a terminal name in the buffer list for example.

Also the console output does not work with the linter, so typing make, the errors won’t be navigable.

Hacking atom

Atom is written in CoffeeScript and Less, CoffeScript and Less are preprocessors for JS and CSS respectively.

So CoffeScript compiles to JavaScript And Less to CSS.

CoffeeScript

From the CoffeScript page: “The golden rule of CoffeeScript is: “It’s just JavaScript”. The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly from CoffeeScript (and vice-versa). The compiled output is readable and pretty-printed, will work in every JavaScript runtime, and tends to run as fast or faster than the equivalent handwritten JavaScript.”

I was a quite worried however that according to the Stackoverflow 2016 survey CoffeeScript is the 5th most dreaded Language! While TypeScript is the #1 Most wanted language. So it does appear like devs are dropping CoffeeScript in favor of TypeScript.

However it seems like Atom is aware of that they are moving to JavaScript ES6 and Babel see: https://github.com/atom/toggle-quotes/pull/26#issuecomment-157341949 http://haacked.com/archive/2016/05/11/encourage-atom/

So new development is done using this thus this is not a problem.

Less

Less is an even simpler transition from CSS. It adds a number of useful things like variables and functions to CSS. You can learn about Less at http://lesscss.org.

This not so easy to understand given my lack of CSS experience… something to come back to…

Making a small plugin

I will refer to the documentation here: http://flight-manual.atom.io/hacking-atom/sections/package-word-count/

But I found that Atom provided some support for the developer to write a plugin, however the more advanced the plugin has to be, the more lacking is the documentation.

Atom is still a young project and any moderately complex plugin will have to update often and read Atom’s code to work properly.

This would need to be investigated much more but it takes a long time especially with my poor Javascript skills.

Conclusion

I think Atom shows a lot of promise, it’s based on web technologies, has a strong community behind it backed my major players like GitHub and Facebook, suffers from no licensing issues, has demonstrated IDEs like platform-io that work with C/C++ embedded development and seems to be very open with design decisions and contributions.

While it has a long way to go achieve feature parity with emacs or Eclipse I think with the momentum it has it can do it in record time.

Also, compared to VS Code, since I investigated that a bit too, the community seems more open and diverse and the licensing is not an issue which in my opinion makes it a better candidate for contributions.

Leave a Reply

Your email address will not be published. Required fields are marked *