diff options
| -rw-r--r-- | a-blogging-challenge.post | 31 | ||||
| -rw-r--r-- | avandu-in-lua.post | 70 | ||||
| -rw-r--r-- | clean-completions.post | 28 | ||||
| -rw-r--r-- | habitrpg.post | 53 | ||||
| -rw-r--r-- | hello-cask.post | 46 | ||||
| -rw-r--r-- | quick-normal-state.post | 47 | ||||
| -rw-r--r-- | rcm-another-dotfile-manager.post | 78 | ||||
| -rw-r--r-- | rogue-legacy.post | 88 | ||||
| -rw-r--r-- | short-excursion.post | 17 | ||||
| -rw-r--r-- | small-recent-posts.post | 31 | ||||
| -rw-r--r-- | syncthing-syncing.post | 62 | ||||
| -rw-r--r-- | testing-with-lua.post | 121 | ||||
| -rw-r--r-- | there-is-an-evil-in-your-emacs.post | 68 |
13 files changed, 740 insertions, 0 deletions
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: --> |