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

Customization

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

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

Performance

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

Conclusion,

• 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

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

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"
(vimish-fold-toggle)
)


(Source)