ryuslash/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Add old posts

Browse source
This commit is contained in:
Tom Willemse 2015-01-02 21:04:36 +01:00
parent 19fbe64c38
commit 586030d970
13 changed files with 740 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
a-blogging-challenge.post Normal file
View file

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

70
avandu-in-lua.post Normal file
View file

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

28
clean-completions.post Normal file
View file

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

53
habitrpg.post Normal file
View file

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

46
hello-cask.post Normal file
View file

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

47
quick-normal-state.post Normal file
View file

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

78
rcm-another-dotfile-manager.post Normal file
View file

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

88
rogue-legacy.post Normal file
View file

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

17
short-excursion.post Normal file
View file

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

31
small-recent-posts.post Normal file
View file

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

62
syncthing-syncing.post Normal file
View file

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

121
testing-with-lua.post Normal file
View file

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

68
there-is-an-evil-in-your-emacs.post Normal file
View file

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