Atom review


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:


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.


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:

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 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.

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 and the rest are independents. See

So starting off with 20% is not bad. Compared with VSCode MS is responsible for 75% of the commits with 18% independents see:


Atom seems to be quite popular making it to the 9th place in the StackOverflow survey (

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: 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


We can see at 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.


In 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.


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.


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.


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.


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.


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.


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.


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.


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:

More experimentation is needed on that subject.


There is (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.


I found this plugin:

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.



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.


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:

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


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

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:

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.


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.

Starting up gdb from Emacs with the right pid automatically

Last week I was developing this patch:

It was full of corner cases, so I wrote many tests, and I debugged each test using gdb often.

That let me to do a lot of: make a test, debug it using gdb, and repeat.

Each time I would need to debug gdb I would look for it’s pid using ps, but that was quite repetitive, way too repetitive for an emacs user.

So there’s now a better way with this little bit of elisp:

(defun gdb-test ()
  "Run gdb with the pid of the gdb currectly executing a test"
  (gdb (concat gud-gdb-command-name (format " -p %s" (system-process-pid "gdb.*-nw.*-nx")))))

(defun system-process-pid (regex-str)
  "Return the pid for a process with args matching regex-str"
  (dolist (pid (list-system-processes))
    (let ((attrs (process-attributes pid)))
      (if (string-match-p regex-str
			  (cdr (assoc 'args attrs)))
	  (return pid)))))

(provide 'custom-lib)

This will find the pid of the gdb under test, assuming that it always has -nw.*-nw it it’s arguments.

So calling M-x gdb-test will start gdb with the pid of the gdb under test et voila 🙂

Random SIGILL on ARM board (Odroid-UX4) with GDB/GDBServer

This is a bug that plagued my development efforts on ARM since the beginning, basically what happens is that randomly GDBServer will fail at running a test with a SIGILL.

This causes regression testing to be very hard, has it generates a lot of false positives due to this error.

I posted to the GDB mailing list about it a while ago see:

For a long time, I had no idea of what the problem could be, I had the intuition that there was some memory race there but the details of it were out of my range of expertise.

Then one day, while at a workshop I discussed the issue a bit with Mathieu Desnoyer (LTTng maintainter), and he hinted that this may be due to ARM having a instruction cache and a separate data cache and that there could be some inconsistencies there.

Now knowing a bit more about what to look for I searched for issues around this area. I found this entry: That explained it well for self modifying code.

But my code was modified by ptrace so I started to look at flush_ptrace_access in the kernel.

With more research around this I found this patch: Which was quite similar to my problem!

Yet I understood very little about the issue, so I decided to contact the author of the patch, Will Deacon.

I exposed the problem to him and luckily he identified the problem quite quickly!!

I tested the solution and it fixed the problem on my Odroid UX4 so it turns at that these SIGILL are due to a SoC Hardware bug as described by Will as such :

“So the problem is that A15 has 64-byte I-cache lines and A7 has 32-byte I-cache lines. That means that if the kernel is doing cache maintenance on the A15, it will issue an invalidation for each 64 bytes of the region it wants to invalidate. The A7 will then receive these invalidation messages, but only invalidate 32 bytes for each one, leaving a bunch of 32-byte holes that didn’t get invalidated.

This is an SoC hardware bug. The two cores should report the same line size (as I mentioned, there’s a tie-off on the A15 to make it report 32-byte cachelines).”

The tie-off documentation can be found in the Technical Reference Manual under “Configuration signals” as IMINLN.

I’ve sent via their Forum the issue to the HardKernel team, I hope they can fix it in their kernel, and in their next hardware board…

Here’s the patch:

diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index ee1d805..573db9b 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -82,10 +82,7 @@
  * on ARMv7.
        .macro  icache_line_size, reg, tmp
-       mrc     p15, 0, \tmp, c0, c0, 1         @ read ctr
-       and     \tmp, \tmp, #0xf                @ cache line size encoding
-       mov     \reg, #4                        @ bytes per word
-       mov     \reg, \reg, lsl \tmp            @ actual cache line size
+       mov     \reg, #32                       @ hack

So I can now do proper regression testing with buildbot!!

A very big thanks to Will for helping me out with this!

Starting this blog/wiki

I’m starting this blog/wiki in order to share what I find while developing.

I have a very bad memory, and I’m used to taking a lot of notes, for a long time these notes were just small text files in a directory with a file name as subject.

This grew into a directory that I could not even grep with grep * since * referred to too many files!

Safe to say it was the bare minimum in terms of organization.

And this is where org mode came to the rescue.

I had been an emacs user for a while around 6-8 years, but I hardly invested time in my configuration and when I did it was mostly to improve my C/C++ environment.

But this last year I decided to allocate more time to it. I started by rewriting everything with the excellent use-package macro and then at some point I tried org mode!

And since then org mode as taken over my note taking, my TODO list, and now I feel I’m organized enough to share stuff online in a way to does not conflict with my work-flow (staying in emacs).

There’s still a lot I’m not happy with but slowly I’m making progress.

I hope this blog/wiki will reflect this progress and serve as reference.

I’m still not clear however on what to post, when to post, what kind of post should I make ? long,short,journal? Is a wiki better ?

But I figured whatever let’s just start writing anything anyway I want and see how it goes otherwise I would never start.