VSCode Insiders 2017 Review - Coming from Emacs

How I set up VSCode

  • I hit C-S-p, selected color theme and chose Solarized Dark
  • C-,, opened settings where I set the font Hasklig, and enabled font ligatures.
  • Installed extensions relevant for the programming modes I use.

Things I immediately miss from Emacs:

  • dired
  • the minibuffer, e.g. open a file from minibuffer.


  • Coming from Emacs, I have the notion that mostly anything that can be thought up can ultimately be customized (via Emacs-Lisp)1,

Things I sort of miss from Emacs

  • org-mode - Always having your note taking tool available (e.g. org-capture).

Things I like about VSCode

  • Built in Zen mode. I like keeping my screen clear from everything but the text sometimes.
  • Section folding built in.
  • The settings configuration mode. It’s quite minimal and smart. Focus in on creating a distributable text file for settings.
  • Markdown preview built in.

Things I strongly dislike about VSCode

  • The hard blue color of the status bar can not be themed as of writing, I read this is about to soon be changed though.

Working in Haskell

  • Working in the programming language Haskell with some extensions, depending on Intero seems to work fine. Terminal integration is nice and auto completion in GHCi does work.


  • In comparison to Atom editor (or LightTable), VSCode launches much faster and seems to perform a lot better. I am surprised that a program based on Electron can perform this well.

What you’re giving up when moving from Emacs to VSCode

  • Using the mouse. Emacs doesn’t need one. VSCode will sometimes need mouse interaction. This can impact workflow.

What’s to be gained from using VScode over Emacs

  • Fonts may look better.
  • Performance may be more reliable.


  • I’m seriously impressed by how mature of an editor VSCode is. I really think they should replace the default “open file” panes with something better (compare Emacs minibuffer, ido and such). I had tried Atom and managed to customize it to a functioning state, but really slow startup times and performance reliability made that editor feel bloated and unacceptably slow and I went back to GNU Emacs.
  • The performance characteristics of GNU Emacs running on Windows are however quite poor in my experience and I even looked at minimal retro editors such as micro-emacs to always have a fast reliable text editor which always start up in under a second. MicroEmacs achieve that but the downsides are many - apart from all the possible functionality one gives up, making text look decent can be very hard, near impossible. Perhaps running a microEmacs in a good terminal emulator is a smart choice, but if you’re on Windows for whatever reason, there really isn’t a good terminal emulator available.

Update, April 1st, 2017:

  • For quickly opening files, there are extensions such as:

Update, April 2nd, 2017:

  1. Of course, the limitation of emacs-lisp are there. Some things in Emacs are after all decided in compiled C code. 

Heroku staging to production

  1. Fork your app

    heroku fork --from myapp --to staging-myapp

  2. Create a heroku pipeline for your app heroku pipelines:create -a myapp
  3. Add the staging app to that pipeline heroku pipelines:add -a myapp-staging myapp
  4. Change the heroku remote to be that of your staging app heroku git:remote -a fedry-staging
  5. From now on we'll be pushing code to staging so your workflow (may be) is: git push heroku master

    .. verify app behavior (heroku open)

    heroku pipelines:promote to send staging -> production without the need for recompile.

More here, and here.

You will now be much less likely to put your "production" app in a broken state.

Note that from now on, your myapp-staging is the target for most of your heroku commands, so if you want to view your production logs - for example - you'll want heroku logs -a myapp.

(f)map with arguments

To map over (\x y -> do print x; putStrLn y):

map (\x -> foo x "my string argument")
map (flip foo "my string argument")

-- < jle`> if you can re-write foo to take the string arugment first, it's even simpler
map (foo "my string argument") [1..10]

-- < MarcelineVQ> if that's inconvenient you can also section it:
map (`foo`"my string argument") [1..10]

23:21 < jmnoz> so it's a good idea to keep possible mapping in mind when setting the argument order (designing the function) then?
23:23 < jle`> jmnoz: actually, yes :)
23:23 < jle`> a lot of people choose argument orders based on what they expect to partially apply

23:23 < jmnoz> hmm also do you use map/fmap interchangeably?
23:23 < jle`> i usually use map for lists, it tends to be slightly more readable
23:23 < jle`> and it can help with error messages sometimes

How to install a recent package in haskell stack

  • create a new project: stack new foo-latest
  • edit foo-latest/stack.yaml, add any needed packages to extra-deps
  • do stack install somepackage-1.20.0 with the package version specified.

This can be useful when LTS (long term support) is lagging behind.

Note: stack might suggest editing the global project stack.yaml, but this might not be the best thing to do.

Emacs: Code folding

Call vimish-fold-toggle when fold-dwim-org/toggle is called.

;; Toggle vimish-fold with Tab key.
(defadvice fold-dwim-org/toggle (after my-fold-dwim-org/toggle (&optional key lst-point) activate)
  "Call vimish-fold-toggle after fold-dwim-org/toggle"


See Also:

  • fold-dwim-org
  • vimish-fold