diff --git a/a-blogging-challenge.post b/a-blogging-challenge.post
new file mode 100644
index 0000000..9857fd7
--- /dev/null
+++ b/a-blogging-challenge.post
@@ -0,0 +1,31 @@
+;;;;;
+title: A blogging challenge
+tags: meta
+date: 2014-06-25 19:20
+format: md
+;;;;;
+
+Lately I've been thinking that I should blog more. I've had a blog for
+as long as I can remember, I'm constantly trying out new platforms or
+new ways of blogging and I never really actually post anything. I
+sometimes get stuck in this spiral of meta-activity where, for
+example, I work hard on getting my blog ready or am figuring out how
+to best present some project I'm working on or its documentation,
+instead of actually blogging or working on/documenting that project. I
+get so bad that I occasionally even have projects around these
+meta-activities, like [edocs](https://github.com/ryuslash/edocs).
+
+Thankfully, after a while I recognize that I'm not actually really
+doing anything and basically just stalling, and I try to do something
+about it. So, I'm going to try to stop doing that and just write.
+Yesterday [I wrote](https://ryuslash.org/blog/?p=37) about
+[HabitRPG](http://habitrpg.org) and now I'm going to try to use that
+to encourage myself to write more blog posts. So far it's starting out
+well, two days and two posts.
+
+So, please excuse my two posts of mostly filler content and I'll try
+to write something a little more interesting tomorrow.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/avandu-in-lua.post b/avandu-in-lua.post
new file mode 100644
index 0000000..18fb328
--- /dev/null
+++ b/avandu-in-lua.post
@@ -0,0 +1,70 @@
+;;;;;
+title: Avandu in Lua
+tags: lua, ttrss, avandu, avandu-lua, projects
+date: 2014-06-27 23:57
+format: md
+;;;;;
+
+A little while ago I started using the
+[Awesome window manager](http://awesome.naquadah.org/) again. I've
+started to play some PC games (such as
+[Rogue Legacy](https://ryuslash.org/blog/?p=44)) and have to use some
+more graphical applications again.
+[Stumpwm](http://stumpwm.nongnu.org) just wasn't quite cutting it and
+suddenly it seemed that my workflow didn't quite fit with a
+completely-manual tiling experience.
+
+So now that I'm back with Awesome I wanted to have a count of the
+number of unread articles in Tiny Tiny RSS in my wibox. I already have
+a project named avandu, which is an Emacs interface for Tiny Tiny RSS,
+and for a little while I used that in combination with Emacs' daemon
+mode to get the number of unread RSS items. This halt my Emacs for a
+few seconds every minute, though, so that was unpleasant. It also
+caused a lot of "Connecting to host: ..." messages to appear in my
+Emacs' echo area, which is a little annoying.
+
+So I decided to write a lua module to get this count, since I didn't
+have a lua project yet. That is
+[avandu-lua](https://github.com/ryuslash/avandu-lua). Right now it
+only implements a `login` and `unread` functions, which allow you to
+log-in to get a session key (so you can do other things), and get the
+number of unread articles (what a shock!).
+
+I've written a bit of
+[documentation](http://ryuslash.github.io/avandu-lua/) for it, hosted
+by github. There isn't much to document of course, but I try.
+
+I still need to add tests, but I'm having difficulty deciding on how
+to do this. [busted](http://olivinelabs.com/busted/) looks really
+nice, but their idea of stubs and mocks doesn't seem to be very useful
+if you're testing a function that calls, for example, `http.call`,
+which returns 4 distinct values, not none. I can't decide if I should
+keep looking, (try to) write something or use `_TEST` checks
+everywhere. I'm leaning towards that last one, perhaps I'll add that.
+
+I don't currently have any concrete plans of extending it to have more
+functions than the ones I've added so far, I might do it for fun at
+some point, or if you'd really like to be able to call Tiny Tiny RSS
+from lua let me know and I might put some more effort into it.
+
+It's been nice to work with lua. I don't particularly love the
+language and it certainly doesn't beat Lisp on any front, but it has
+its moments and niceties.
+
+Some things that still need to be done:
+
+- As I said, I need to add tests.
+
+- I think I should try to see if coroutines can be used, it seems to
+  hang Awesome now on occasion.
+
+- Add license info. Yeah I really should almost do this before I do
+  anything else when I start a new project. It's going to be LLGPL in
+  any case.
+
+- Release an actual version. Always installing from just a git
+  checkout can be a little annoying.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/clean-completions.post b/clean-completions.post
new file mode 100644
index 0000000..6f39e77
--- /dev/null
+++ b/clean-completions.post
@@ -0,0 +1,28 @@
+;;;;;
+title: Clean completions
+tags: emacs, tips, visual
+date: 2014-07-08 19:19
+format: md
+;;;;;
+
+Today's post is very short. In my quest to make GNU Emacs look ever
+better I thought about something new (to me). Not all buffers need
+have a mode line. As such I will now turn off the mode line for
+`completion-list-mode`, since that only shows up for a short while and
+I've so far never had any trouble distinguishing it from other
+buffers.
+
+``` emacs-lisp
+(add-hook 'completion-list-mode-hook
+          (lambda () (setq mode-line-format nil)))
+```
+
+Now, whenever a completion buffer pops up, it'll use all the space
+available, including the line where the mode line used to be. If it
+shows up just above the minibuffer (which for me it always has done)
+it looks more like a part of the same thing instead of two separate
+windows.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/habitrpg.post b/habitrpg.post
new file mode 100644
index 0000000..49d379c
--- /dev/null
+++ b/habitrpg.post
@@ -0,0 +1,53 @@
+;;;;;
+title: HabitRPG
+tags: software, tasks, todo
+date: 2014-06-24 23:57
+format: md
+;;;;;
+
+A quick post just to have written one, it's been awhile...
+
+[HabitRPG](https://habitrpg.com/#/tasks) is a to-do application unlike
+many others. It gamifies your task list by adding Role Playing Game
+elements. You create a character, you have HP, XP, (eventually) MP and
+gold. There are three categories of tasks: habits, dailies and to-dos.
+They're colored from red (bad) to yellow (neutral) and blue (good).
+Not completing dailies will cost you HP and turn them red, leave them
+incomplete for too long and your character will die and lose a level.
+You gain XP and coins by completing tasks. You can use your MP for
+certain special abilities, for example strike hard at a task and shift
+its color more towards blue. You can use coins to buy rewards, either
+self-made or thought-up by the HabitRPG developers.
+
+You can also start a party and go questing with friends, or join a
+guild. There are also challenges, which are sets of tasks specified by
+someone else, as a challenge.
+
+I've tried many a to-do application. I've even tried writing my own a
+few times. I've never really been satisfied. For a long while now I've
+been using [org-mode](http://orgmode.org) for Emacs, both because it
+is Emacs and because it flexible enough to change completely to your
+own needs. The only problems remaining are identifying your needs and
+keeping up with your task list. Both are tricky to me, but that last
+one gets worse the bigger my task list gets.
+
+Unexpectedly, HabitRPG's rewards and random loot are stimulation
+enough for me to keep completing tasks. I've been using it for a
+couple of weeks now and I'm still completing stuff, which is quite
+unusual for me. And I put lots of stuff in there, such as "Drink
+water", which is a habit I want to stimulate; or "Exercise" (three
+days a week as a daily), which is something I've been needing to do in
+a long time and so far I'm keeping it up well; or single tasks like
+"Clean up `~/projects`", which I've yet to do.
+
+I suppose it helps that I've always liked computer RPGs, and this
+wouldn't work if I didn't feel that the reward of being able to buy a
+new weapon for my character is any kind of motivation.
+
+Anyway, if you have trouble motivating yourself to actually complete
+tasks on your to-do list and it sounds like fun to you, you might try
+it.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/hello-cask.post b/hello-cask.post
new file mode 100644
index 0000000..871ea68
--- /dev/null
+++ b/hello-cask.post
@@ -0,0 +1,46 @@
+;;;;;
+title: Hello, Cask
+tags: emacs, config, cask
+date: 2014-01-31 23:17
+format: md
+;;;;;
+
+I've been very resistant to looking at [Cask](http://cask.github.io/).
+I felt that, much like for example el-get, it was trying to re-solve a
+problem that has been solved by ELPA since Emacs v24 in a way
+incompatible with ELPA.
+
+I have finally looked at it, and to my pleasant surprise it works
+*with* ELPA instead of beside it, as a wrapper adding some extra
+functionality. Using and supporting Cask doesn't mean you don't
+support ELPA. And theoretically using Cask does open up possibilities
+for development by creating separate development environments (package
+wise), though I haven't tried this out yet.
+
+I've switched over my configuration to using Cask, which will also
+help me keep the configuration on my laptop synchronized more easily.
+
+Aside from a fairly long Cask file, making it work is pretty simple,
+as the website [suggests](http://cask.github.io/usage/).
+
+``` emacs-lisp
+(eval-and-compile
+  (require 'cask "~/projects/ext/cask/cask.el")
+  (cask-initialize))
+```
+
+I add an `eval-and-compile` so the external process compiling my
+`init.el` doesn't complain about not being able to load ELPA-installed
+packages.
+
+Now instead of starting up Emacs, running `M-x list-packages`,
+pressing `U` and then `X` (and `y` at least once) it's a matter of
+
+    cd ~/.emacs.d
+    cask update
+
+Much easier.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/quick-normal-state.post b/quick-normal-state.post
new file mode 100644
index 0000000..6dfe67a
--- /dev/null
+++ b/quick-normal-state.post
@@ -0,0 +1,47 @@
+;;;;;
+title: Quick normal-state
+tags: emacs, evil
+date: 2014-07-11 00:47
+format: md
+;;;;;
+
+I realized today that most of the time (over 90%) of the time I save a
+file I feel I have finished typing something. Typing this out makes it
+sound very obvious, actually. One other thing I noticed is that I
+still forget to return to normal-state after I'm done editing. Emacs
+being hackable and not being content with twisting my brain to suit my
+editor but rather twisting my editor to suit me, I thought I might
+automate it a little.
+
+My first idea was to have evil automatically revert to normal-state
+whenever I save and also whenever I switch buffers. I haven't found a
+hook that runs when switching buffers, so I'll need to brush up on my
+advising skills and have it run just before switching, perhaps even
+when `execute-extended-command` or `smex` run, so any explicit minibuffer
+action returns to normal state.
+
+For now it's just the save file, and only for buffers that aren't in
+the emacs-state as default list:
+
+``` emacs-lisp
+(defun modes-starting-in (state)
+  "Get a list of modes whose default state is STATE."
+  (symbol-value (evil-state-property state :modes)))
+
+(defun maybe-switch-to-normal-state ()
+  "Switch the current buffer to normal state.
+
+Only do this when the mode is not in emacs state by
+default."
+  (unless (memql major-mode (modes-starting-in 'emacs))
+    (evil-normal-state)))
+
+(with-eval-after-load 'evil
+  (add-hook 'after-save-hook
+            #'maybe-switch-to-normal-state))
+```
+
+I personally only use either normal-state or emacs-state as default
+states when a mode loads, if you want to check more you'll have to add
+some more calls to `memq` and change `emacs` to, for example `insert` or
+`visual` or whichever you need.
diff --git a/rcm-another-dotfile-manager.post b/rcm-another-dotfile-manager.post
new file mode 100644
index 0000000..b3526a3
--- /dev/null
+++ b/rcm-another-dotfile-manager.post
@@ -0,0 +1,78 @@
+;;;;;
+title: rcm: Another dotfile manager
+tags: software, rc
+date: 2014-07-03 17:53
+format: md
+;;;;;
+
+A little while ago I saw a link pass by about
+[rcm](http://robots.thoughtbot.com/rcm-for-rc-files-in-dotfiles-repos),
+a RC file (or dotfile) manager. It seems a lot like using
+[GNU Stow](https://www.gnu.org/software/stow/) for your dotfiles.
+
+The basic idea seems to be that you create links to all your dotfiles
+and the actual files are all kept in a single directory structure,
+presumably for easy sharing with, for example, git.
+
+## The good...
+
+It seems that rcm has a few interesting features.
+
+### Host-specific dotfiles
+
+It gives you an option to have host-specific dotfiles, which is very
+handy when you're working on multiple (types of) system. My laptop
+doesn't always have the same needs as my PC and my server(s)
+definitely have different needs.
+
+## The bad...
+
+In the short time I've spent with it, I've also found a few things I
+don't much like.
+
+### Everything in a single directory
+
+I'm not so sure about the choice to put everything in a single
+directory structure, which top-level dotfiles in the top-level
+directory. This links all the files together in a repository-idea
+kind-of way. I can't have a zsh repository and an Emacs repository
+without also having different rcm source directories.
+
+Actually, this isn't entirely true. I can still separate them, with
+the use of [labels](#labels), but not in an ideal fashion.
+
+### Unfriendly to directories
+
+It doesn't seem to like linking directories, though it can. Linking
+directories is essential for me as I can on occasion remove a file
+from one of my configuration directories and I don't want to have to
+keep track of dead links like that manually. If you do link a
+directory, instead of it showing up in `lsrc` as a single entry, all
+the files in the directory are shown separately.
+
+<a name="labels"></a>
+### Labels
+
+The labels are a nice idea, but they aren't what I expected them to be
+when I read the description. Like host-specific dotfiles, labeled
+dotfiles are put in their own directory. This allows you to separate
+the dotfiles from others. What I didn't like about this implementation
+is that afterwards you always have to specify which label you want to
+use, which seems to make it impossible to still setup your dotfiles in
+a single command.
+
+## Conclusion
+
+I personally won't be using rcm to manage my dotfiles. The solution I
+have right now with GNU Stow works better and is easier to setup,
+although that too has its drawbacks.
+
+This is not a definitive description or review of the software, I have
+spent only a small amount of time with it and these are the findings I
+made when trying to set it up with a few config files. If you really
+want to know about it you should try it, it has quite a bit of
+documentation to get you going.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/rogue-legacy.post b/rogue-legacy.post
new file mode 100644
index 0000000..848657c
--- /dev/null
+++ b/rogue-legacy.post
@@ -0,0 +1,88 @@
+;;;;;
+title: Rogue Legacy
+tags: games
+date: 2014-06-26 22:01
+format: md
+;;;;;
+
+A little while ago [Rogue Legacy](http://www.roguelegacy.com/) was on
+sale on [gog.com](http://www.gog.com) and it looked like fun, so I
+bought it. Today I "finished" it, by which I mean that I killed the
+big boss and get to start over. There are still a lot of things I can
+(try to) do, but the "story" is over.
+
+So, at the start of this game you are a legendary knight and you go
+into this castle, for what reason is not explained until later. This
+game is about his children, somehow. At the end of the tutorial the
+knight dies and a child of his will take his place and walk into the
+very same castle, possibly to avenge their father.
+
+Each time you die you get to pick a new child to work with, each has a
+class which affects certain stats and each may have one or two traits.
+These traits can be useful, funny, annoying or sometimes even make you
+sick. Some traits include being near-sighted, having no pulse in your
+feet or being a giant. They make for some interesting experiences and
+some laughs as well. Classes include a Paladin which isn't
+particularly good at anything, an Archmage which has a lot of magic
+power, and a Knave which is pretty bad at everything except has a
+killer critical hit.
+
+Every time you enter the castle it will normally be completely
+different from last time, save for a few constants. In my opinion this
+makes it vastly replayable, as every time you have to start over
+everything is new.
+
+Thankfully this is not such a cruel game that every time you die you
+have to start over from scratch. Each run through the castle will
+result in some gold, this gold can be used by the next generation to
+buy some upgrades, and thus level up. So even if you are exceptionally
+bad at a game like this, as I probably am myself, you'll still be able
+to make progress simply by trying over and over again. Of course there
+are also better armors and weapons to be bought and runes to be
+equipped to help you even more.
+
+The gameplay is very nice. It's very action/platform in nature as
+there is a lot of swinging of the sword, dodging of projectiles and
+jumping on platforms to be had.
+
+# Installation on linux
+
+The game is available for linux, although since I bought it through
+gog.com I only had an option of windows or mac. I didn't try asking
+the developers if they could let me download the linux version since I
+didn't think to check if there was one until I was already well
+underway with my game.
+
+It works in wine, version 1.7.20, at least. To install it in wine
+first you'll need to have the proper XNA installed. On my Archlinux
+installation this was a matter if installing winetricks and then using
+it to install `xna`:
+
+    sudo pacman -S winetricks
+    winetricks xna
+
+I didn't fully test it with a normal 64-bit wine prefix, but using a
+32-bit one worked fine for me. After having installed XNA installation
+of Rogue Legacy went fine and I didn't have any trouble playing it at
+any point. On my laptop that is a different story, I just can't get it
+installed there, even though it's the same version of everything I can
+think of (it also has Archlinux installed).
+
+# Conclusion
+
+It's a very nicely designed game, both visually and gameplay-wise.
+There are a lot of funny things in it and a lot of things for you to
+find. You start out thinking you'll never ever be able to go through
+the entire castle (or at least I did) only to find that gradually you
+learn the enemies' ways and get stronger and things get easier, and
+then you find a boss (and subsequently lose hope again, or at least I
+did).
+
+It took me some 34 hours and some minutes to kill the big boss and 136
+generations of heroes, it was my first play through and I have to say
+I was a little addicted during those hours, I haven't played a game
+this much in a very long time.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/short-excursion.post b/short-excursion.post
new file mode 100644
index 0000000..bae6d85
--- /dev/null
+++ b/short-excursion.post
@@ -0,0 +1,17 @@
+;;;;;
+title: Short excursion
+tags: meta
+date: 2014-07-08 20:24
+format: md
+;;;;;
+
+I took a short excursion to the [Ghost](https://ghost.org/) blogging
+platform, which I installed locally, just to try it out. I've been
+keeping up my posts there, though I did decrease the number. Posting
+every day is too much of a strain still, so I've decided to post once
+every two days, tuesdays, thursdays and saturdays. I've just copied
+the posts over from Ghost to here.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/small-recent-posts.post b/small-recent-posts.post
new file mode 100644
index 0000000..9ec7108
--- /dev/null
+++ b/small-recent-posts.post
@@ -0,0 +1,31 @@
+;;;;;
+title: Small Recent Posts
+tags: projects, wordpress, small-recent-posts
+date: 2014-08-16 13:39
+format: md
+;;;;;
+
+I've been reading
+[Professional WordPress Plugin Development](http://www.wrox.com/WileyCDA/WroxTitle/Professional-WordPress-Plugin-Development.productCd-0470916222.html)
+the last few weeks and I finally got around to putting some of what
+I've read (a tiny bit) to use.
+
+I've written my
+[first WordPress plugin](https://github.com/ryuslash/small-recent-posts).
+It's part of a larger project of mine to replace my
+[[http://orgmode.org][Org-mode]] powered static site with WordPress
+and learn about WordPress plugin development along the way.
+
+Right now, it only shows the 5 latest posts, much like the widgets in
+the side-bar and admin area do (except with less options I'm sure). My
+plans are simple, just a number of posts and possibly a tag or
+category.
+
+For now I don't have any place for you to see it in action, but
+hopefully soon. To use it just add `[[recent]]` anywhere in your post
+or page. It is meant to be used in pages, but there is no technical
+reason why it couldn't also be used in posts.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/syncthing-syncing.post b/syncthing-syncing.post
new file mode 100644
index 0000000..f655ef8
--- /dev/null
+++ b/syncthing-syncing.post
@@ -0,0 +1,62 @@
+;;;;;
+title: Syncthing: Syncing...
+tags: software, file-synchronization
+date: 2014-07-05 22:06
+format: md
+;;;;;
+
+[SyncThing](http://syncthing.net/) is a very interesting distributed
+file sharing option. It is a lot like (what I understand of) Dropbox
+and the file sharing capabilities of ownCloud, as well as
+SparkleShare, SeaFile and others. The biggest difference compared to
+all of these, though, is that SyncThing is distributed, or
+peer-to-peer, there is no central server used in the file sharing.
+
+Setting it up is a breeze. Install it, run it and you're almost done.
+Once you have it installed on at least two computers (or know someone
+else who has installed it), you have to let them know eachother. You
+do this by exchanging their node ids. SyncThing know two things: Nodes
+and Repositories. Nodes are the different machines you want to share
+with and repositories are the different directories you want to share
+with certain nodes. Exchanging node ids requires an actual exchange.
+If you're managing both machines yourself it shouldn't be too hard to
+manage, if you're sharing with someone else you need another channel
+of communication to get this data across. Once you've exchanged node
+ids and your firewall is setup properly (it needs to let through a
+special TCP port for global discovery) your machines will connect. If
+you're both on a local network it should happen quickly, if you're
+across a large gap of land it should still happen fairly quickly.
+
+After both your machines are connected, or even before, you should
+setup some repositories and share them with the node you just
+connected with, otherwise nothing will happen. Again there's some
+communication involved here, because both sides will have to share a
+repository with the same name. If either side doesn't share a
+repository with the other side, it won't sync. After you've
+communicated which names to use, though, all should go smoothly. It
+check once every 60 seconds whether or not anything's changed and if
+it has it'll try and sync with the other machine(s).
+
+One downside to this program, at least on Linux, compared to ownCloud,
+at least using the ownCloud Client, is that there is no notification
+of newly arrived files. So again you'd have to send the person owning
+the node you're sharing with a message telling them that something new
+should be waiting for them.
+
+A very nice thing on the other hand, is that everything is encrypted.
+And because there's no central server involved, only the people you
+choose to share with (and possibly they choose to share with) will
+have the files. There is no single server that can get hacked into
+where all your files can be found. It's also open source, which of
+course makes it possible for you, or anyone else, to look at, improve,
+audit or do anything with the code you want to or need to to ensure to
+yourself that it's not doing anything it shouldn't be doing.
+
+I haven't been able to test it thoroughly in the real world. I'm
+currently just sharing between my desktop PC and my laptop, and I'm
+sharing with a good friend of mine. So I'm looking forward to seeing
+more of it.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/testing-with-lua.post b/testing-with-lua.post
new file mode 100644
index 0000000..96ac477
--- /dev/null
+++ b/testing-with-lua.post
@@ -0,0 +1,121 @@
+;;;;;
+title: Testing with Lua
+tags: projects, lua, testing, ci, avandu-lua
+date: 2014-06-30 23:32
+format: md
+;;;;;
+
+Last time I wrote about my project
+[avandu-lua](https://ryuslash.org/blog/?p=51) and I mentioned how I
+was having some trouble testing the different types of functions. I've
+since found a way to mock the functions in such a way that I can
+safely test functions with IO operations without having to actually
+perform them. It seems that Lua modules are mutable. Perhaps this
+isn't strange given that Lua modules are basically tables, but I
+hadn't considered it before. I'm not entirely sure if it is a language
+feature or just something that happens to be true right now, so this
+method of mine might soon become useless.
+
+# Testing operations
+
+So, to test these functions that would normally have side-effects or
+would require a lot of extra work setting up to work correctly, we
+basically have to replace the existing functions. Normally in a
+running program you really wouldn't want to do this, save for when you
+have dynamic scope, which I haven't yet found in Lua.
+
+So I want to test that everything works properly when the `io.access`
+function reports it can't access a certain file, I'd change the
+function like so:
+
+```
+-- You must first require it, so you have the same module.
+local posix = require 'posix'
+
+-- ...
+
+posix.access = function ()
+   return false
+end
+```
+
+This way I know what the function will do, when it eventually gets
+called.
+
+# Travis-CI
+
+After finally getting some tests in my project and making sure that I
+have full test coverage of my module, I thought it would be fun to see
+if I could automatically test everything with travis-ci. It was a
+little challenging because I don't normally run Ubuntu or Debian, so I
+don't know what they name their packages, and one of my dependencies
+(luasec) had some trouble finding the libssl library.
+
+After a little poking around, a few retries and a false-success, it's
+now finally running:
+
+<div class="center">
+  <a href="https://travis-ci.org/ryuslash/avandu-lua">
+    <img src="https://travis-ci.org/ryuslash/avandu-lua.svg?branch=master" />
+  </a>
+</div>
+
+My `.travis.yml` is pretty simple:
+
+```
+language: erlang
+
+env:
+  - LUA="lua"
+
+branches:
+  except:
+    - gh-pages
+
+install:
+  - sudo apt-get update
+  - sudo apt-get install luarocks libssl1.0.0
+  - sudo luarocks install busted
+  - sudo luarocks install luasocket
+  - sudo luarocks install luasec OPENSSL_LIBDIR=/usr/lib/x86_64-linux-gnu
+  - sudo luarocks install luajson
+  - sudo luarocks install luaposix
+
+script: "busted -m 'lua/?.lua' -o TAP"
+
+# ...
+```
+
+I'm using the `erlang` environment, because there isn't a Lua one
+(yet). I've written my library for lua, not luajit, so busted needs to
+know which to run, it always runs luajit first it seems. I don't need
+the tests to be run again when the `gh-pages` branch is updated, since
+that has nothing to do with the code itself, I would actually like to
+have tests run on all other branches.
+
+Then we get to the dependencies. Nothing major except for the luasec
+dependency. I'm not entirely sure how long that `OPENSSL_LIBDIR` will
+remain where it is now, but it works for now. I didn't discover the
+location myself, I found it on
+[someone else's](https://github.com/ignacio/redis-luanode/blob/a50a7e5a9d0bd0c61b6ce7e445b278f2f184c792/.travis.yml#L41)
+`.travis.yml` as a comment.
+
+Lastly we have the script. Since the tests live in `/spec` and the
+code lives in `/lua` I run the tests from the project root and include
+the `lua` directory in the module path. I use TAP output because with
+the default output failures also return `0`, when a failure occurs
+with the TAP output, a non-0 exit status is returned and travis knows
+they didn't pass. That is why build 6 passed even though there was
+still a failed test.
+
+The rest is notification settings which isn't interesting enough to
+duplicate here.
+
+# Still to do
+
+Now I should start expanding it a little. Well, actually I *still*
+need to add the proper license information.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->
diff --git a/there-is-an-evil-in-your-emacs.post b/there-is-an-evil-in-your-emacs.post
new file mode 100644
index 0000000..537b5b2
--- /dev/null
+++ b/there-is-an-evil-in-your-emacs.post
@@ -0,0 +1,68 @@
+;;;;;
+title: There is an Evil in your Emacs
+tags: emacs, vim, editors
+date: 2014-07-01 21:44
+format: md
+;;;;;
+
+When I first started using GNU/Linux I was looking for a proper text
+editor. I only had any experience with Visual Studio on Windows
+because I was a .Net developer at the time, and didn't really have
+much of a choice. One of the main things I wanted was an editor that
+worked in a terminal.
+
+Naturally I came to Vim and Emacs (as well as Nano, and perhaps some
+others as well). For a few weeks I kept switching between Vim and
+Emacs. I liked Vim's syntax highlighting better, but on the other hand
+I liked Emacs' keybindings/modelessness better as well. I ended up
+going with Emacs mostly because of Vim's moded editing.
+
+For years the thought of Vim's moded editing gave me nightmares. I
+never really realised the best thing about Vim. Even when a post
+appears on Stack Overflow about grokking Vim. I was already so blinded
+by the idea that Emacs was the superior editor for me that I failed to
+register the information. It took a long time, but eventually I opened
+up to the possibility of such moded editing. By now I was stuck with
+Emacs because I just couldn't give up its customizability or
+extensibility. Also, I've grown to love Lisp, and specifically Emacs
+Lisp, so to go from that to Vimscript wouldn't be quite ideal.
+
+Eventually I decided I really did want to try it. Thankfully Emacs has
+a package for that: Evil, the Extensible Vi Layer for Emacs. There is
+one other problem, though: I use the Colemak keyboard layout. The
+usual `hjkl` keys are more like `hynu`, with the up key at the bottom
+of the keyboard, down at the top and left and right diagonally from
+eachother. Again Emacs has a package for that, `colemak-evil`. It
+rebinds some of the keys so that Evil will work with the Colemak
+keyboard layout. It is based on that the creator of the Colemak layout
+used to use in Vim. It's a bit aggressive, so I customized it to be a
+little less so, mostly removing rebindigs from the motion and emacs
+state maps.
+
+The real power is in the composability of the commands. In Emacs you
+have commands like `forward-kill-word`, `forward-kill-sexp` and
+`forward-kill-char`. In Vim you have the `delete` operation, which can
+be combined with, for example, the `forward-word` motion, or the
+`next-line` or `forward-char` motion. I probably have the names wrong,
+but hopefully they convey the meaning of what they do. This is what it
+is all about, or at least from what I've learned to use so far. Of
+course the powerful ed-like editing features called forth through the
+Vim `ex` mode, such as `%s/find/replace`. Lastly, of course, the fact
+that a lot of editing can be done in normal mode helps in preventing
+Emacs-pinky.
+
+I haven't yet been able to work with the extensible part, but some of
+the modules that exist for evil speak volumes of it.
+
+If you are interested in increasing your productivity, or you like to
+experiment with new things, you might really want to try it. It may
+not completely be Vim, but it's still completely Emacs. If you use the
+colemak-evil package as well you'll also notice that in the insert
+state all your regular Emacs keys work normally, which is a great
+combination of the two editors. So far I feel that Vim is great for
+editing existing code and text, but Emacs still feels better when
+writing a lot of new code or text.
+
+<!-- Local Variables: -->
+<!-- mode: markdown -->
+<!-- End: -->