Moxley Stratton

Considering a switch to the Atom Text Editor?

Published Mar 16, 2014 by in Coding, Atom, Text Editors at http://www.moxleystratton.com/considering-a-switch-to-the-atom-text-editor/

You’ve probably heard of Atom, Github’s new text editor. Read these checklists to help you decide whether it’s an editor worth switching to.

General Pros

  • Open Source
  • High-quality extension and enhancement infrastructure
  • View is programmable using good old HTML DOM and CSS
  • Well-known API model (NodeJS)
  • Built-in Github integration
  • Built-in, light Git integration
  • Realtime Markdown preview
  • Seamlessly tracks external file renames while the file is open
  • Browse archive files, like zip or tar.gz, like Emacs does.
  • UI and editing features basically a clone of Sublime Text
  • Free, while in Beta.

General Cons

  • In Beta. Some rough UX details.
  • No keyboard macros
  • No command documentation
  • Difficult to discover available commands
  • Currently only works on OS X (Windows and Linux planned)

For Sublime Users

Pros

  • Package manager is built in
  • Deep customization API
  • Fine-grained commands
  • Complete pane splitting and pane navigation
  • Smarter indentation of pasted text

Cons

  • 2-3x slower, 2-3x more memory than ST3 (realistically, it’s not as bad as it sounds)
  • No “Jump Back” feature, as found in ST3
  • No auto-highlighting matching strings of selected string
  • Can’t open file in existing window, unless it lives within the window’s directory
  • Missing key bindings for many search & replace operations

For Vim and Emacs Users

Pros

  • Modern Application and UI, contemporary key bindings
  • Easy to learn
  • Built in Package manager, and standard package formats
  • View is good old HTML DOM, CSS
  • CoffeeScript is arguably better than eLisp and Vimscript
  • Editor API reaches deep into the editor
  • Project-wide fuzzy file finder, built in, fuss-free
  • Buffer-wide fuzzy symbol finder, built in, fuss-free
  • Project-wide string search
  • Large number of homerow-close key bindings (many of them are Emacs compatible)
  • Pane splitting on par with Vim and Emacs
  • Multi selections
  • Code Snippets

Cons

  • Editor API doesn’t go as deep as Emacs. Lacks rich callback API that Emacs has.
  • No cursor history, so no command for going back to the last location without using bookmarks
  • No cursor navigation around, or editing operations on, symbol definitions (e.g., methods)
  • Unlike Emacs, no built-in shell console (package under development)
  • Keyboard navigation of file tree is cumbersome, but will likely improve over time.
  • Missing a lot of the cool text navigation and editing commands available to Vim and Emacs

Story logo

© 2018