Initial commit

auto-suggestions-for-duckduckgo-in-conkeror.post

@@ -0,0 +1,68 @@
+;;;;;
+title: Auto-suggestions for DuckDuckGo in Conkeror
+tags: conkeror, config
+date: 2014-06-03 22:08
+format: md
+;;;;;
+
+Recently [DuckDuckGo](https://duckduckgo.com) gave its UI a big
+overhaul. One of the new parts of the UI is the auto-suggestions,
+which are pretty cool, especially when working with `!bang` syntax. I
+want that in my conkeror webjump! So I started looking...
+
+Turns out that [Conkeror](http://conkeror.org) can work with
+[OpenSearch](https://en.wikipedia.org/wiki/OpenSearch) descriptions to
+create webjumps and actually already has a DuckDuckGo OpenSearch XML
+file. However, DuckDuckGo has a newer version of that file.
+
+So, for starters you should download the proper XML
+[file](https://duckduckgo.com/opensearch.xml). After this, you can
+replace the `/usr/share/conkeror/search-engines/duckduckgo.xml`
+file[<sup>1</sup>](#fn1) with the newly downloaded one and you'd be
+done, ready to use the new auto-suggest
+functionality[<sup>2</sup>](#fn2).
+
+If, however, you don't like overwriting your package's files because
+they may get overwritten again in the future[<sup>3</sup>](#fn3) or
+you really don't think it's proper, you can also create a custom
+webjump that does the same thing, which is what I did.
+
+In case you are following my lead, first we'd need to put the
+downloaded XML file somewhere. I suggest
+`~/.conkerorrc/search-engines` because that way everything in your
+configuration stays nice and contained, although you might want to put
+it in your
+`~/.conkeror.mozdev.org/conkeror/CODE.PROFILE/search-engines`, where
+`CODE` is an eight-character alphanumeric sequence (as far as I can
+tell) and `PROFILE` is the name of the profile you
+use[<sup>4</sup>](#fn4), because that should already be included in
+your `opensearch_load_paths`.
+
+If you put the XML in your `.conkerorrc` you'll need to add that
+directory to your `opensearch_load_paths`, so put something like the
+following in your `init.js`, or whichever filename you use for your
+conkeror init:
+
+    opensearch_load_paths.push(make_file("~/.conkerorrc/search-engines"));
+
+After Conkeror knows where to find your custom search engine
+specifications you can create a webjump for it:
+
+    define_opensearch_webjump("ddg", "ddg.xml");
+
+Once you evaluate these lines or restart your Conkeror, you should
+have a `ddg` webjump with auto-suggestion. Yay!
+
+## Footnotes
+
+<a name="fn1"></a> I have Conkeror installed in `/usr`, so if you have
+it installed somewhere else your path will be different.
+
+<a name="fn2"></a> You might have to restart Conkeror first, I didn't
+test it without restarting.
+
+<a name="fn3"></a> This can of course happen when, for example, your
+package manager updates your Conkeror installation.
+
+<a name="fn4"></a> The default profile is named (appropriately)
+`default`.

c-d-to-close-eshell.post

@@ -0,0 +1,61 @@
+;;;;;
+title: C-d to close eshell
+tags: eshell, emacs, elisp, config
+date: 2013-08-17 02:25
+format: md
+;;;;;
+
+One of the "tricks" that I have learned to use when working with
+terminals is using `C-d` to close them, or when working on a TTY
+logout. It somehow grew to the extent that if I can't use it, I get
+annoyed, like with `eshell`.
+
+I have customized `ansi-term` to immediately close its buffer after the
+shell quits. This makes it very easy to start an `ansi-term`, which I've
+bound to `C-c t`, run a quick command (perhaps `make`, or similar), `C-d`,
+and I'm out. I want that for my `eshell` too.
+
+There are a few conditions that I want met before the buffer is
+killed, though.
+
+1. Since `eshell` is an Emacs mode like any other, `C-d` is usually used
+   to forward-kill characters, I don't want to lose this.
+2. I only want it to quit when the line of input is empty.
+
+The following piece of code make sure these conditions are met.
+
+1. It interactively calls `delete-char`, which keeps keybindings like
+   `C-4 C-d` to delete 4 characters working.
+2. It catches the error condition which is signaled whenever
+   `delete-char` can't do it's job (like when there's nothing left to
+   delete in the buffer).
+3. It checks to make sure that the signaled error is the `end-of-buffer`
+   error. I don't want to kill the buffer if I try to delete more
+   characters than are in the buffer because I feel that could cause
+   irritating surprises.
+4. It checks of the cursor is at the `eshell` prompt. This, combined
+   with only responding to the `end-of-buffer` error, makes sure we're
+   on an empty line and not just at the end of the input. Sometimes
+   keys are pressed at the wrong time and I don't want to have to
+   re-type a command just because I was being an idiot.
+5. If the right conditions aren't met, signal the error again so I can
+   see what's going on.
+
+``` emacs-lisp
+(defun eshell-C-d ()
+  "Either call `delete-char' interactively or quit."
+  (interactive)
+  (condition-case err
+      (call-interactively #'delete-char)
+    (error (if (and (eq (car err) 'end-of-buffer)
+                    (looking-back eshell-prompt-regexp))
+               (kill-buffer)
+             (signal (car err) (cdr err))))))
+```
+
+I then bind this to `C-d` in eshell.
+
+``` emacs-lisp
+(add-hook 'eshell-mode-hook
+          (lambda () (local-set-key (kbd "C-d") #'eshell-C-d)))
+```

installing-hla-on-archlinux.post

@@ -0,0 +1,83 @@
+;;;;;
+title: Installing HLA on Archlinux
+tags: hla, archlinux, vagrant
+date: 2014-12-27 21:43
+format: md
+;;;;;
+
+I recently started reading
+[The Art of Assembly Language, 2nd Edition](http://www.nostarch.com/assembly2.htm).
+It uses High-Level Assembly language in its code examples and this
+requires a special compiler, or assembler, to turn your code into
+machine code.
+
+## Fixing the PKGBUILD
+
+The compiler, `hla`, is available on the Archlinux User Repository
+[here](https://aur.archlinux.org/packages/hla/). At the time of
+writing, though, that `PKGBUILD` doesn't work entirely. By default
+pacman removes all static libraries from the created packages, which
+took me a while to find out. Adding the following line to the
+`PKGBUILD` fixes it:
+
+    options=(staticlibs)
+
+I also placed a comment on the AUR page, but there has been no sign
+of acknowledgment so far.
+
+## Running on x86_64
+
+After having installed the compiler I got a lot of errors compiling
+my very simple hello world application, as typed over from the
+book. The gist of them was that it couldn't create 64-bit
+executables, which isn't very surprising as HLA seems to be only
+for x86 (32-bit) architecture. Another comment on the AUR page
+helped that though. One should add the `-lmelf_i386` switch to the
+`hla` command-line. So I put in my `~/.zshrc`:
+
+    alias hla="hla -lmelf_i386"
+
+This discovery only came after a few other attempts to install HLA.
+
+## Alternative: Using Vagrant
+
+Before I'd read about the `-lmelf_i386` command-line switch I was
+looking at ways to run a 32-bit operating system inside my
+Archlinux installation. There are a few options I'm familiar with:
+lxc, Docker and Vagrant.
+
+At first I tried to create a 32-bit Archlinux container, but the
+installation script failed, so I couldn't get that started. Then I
+went on to Vagrant, which worked pretty quickly.
+
+I used the `ubuntu/trusty32` box, which can be downloaded by calling:
+
+    vagrant box add ubuntu/trusty32
+
+A very short `Vagrantfile`:
+
+    # -*- mode: ruby -*-
+    # vi: set ft=ruby :
+
+    Vagrant.configure(2) do |config|
+      config.vm.box = "ubuntu/trusty32"
+      config.vm.provision :shell, path: "vagrant.sh"
+    end
+
+and then the provision in `vagrant.sh`:
+
+    wget http://www.plantation-productions.com/Webster/HighLevelAsm/HLAv2.16/linux.hla.tar.gz
+    tar --directory / --extract --file linux.hla.tar.gz
+
+    cat > /etc/profile.d/hla.sh <<EOF
+    #!/usr/bin/bash
+
+    export hlalib=/usr/hla/hlalib
+    export hlainc=/usr/hla/include
+    export hlatemp=/tmp
+    export PATH="${PATH}:/usr/hla"
+    EOF
+
+After that you can just call `vagrant up`, wait a while and then have
+fun playing around with HLA in an Ubuntu 14.04 environment.
+

mounting-music-dir-before-mpd.post

@@ -0,0 +1,39 @@
+;;;;;
+title: Mounting music dir before MPD
+tags: systemd, mpd, config
+date: 2013-11-24 14:03
+format: md
+;;;;;
+
+Systemd allows you to specify a program to run before running the main
+daemon (or program) with `ExecStartPre`. This can, for instance, be
+used to run a mount command before starting `mpd`. By adding under the
+`[Service]` heading:
+
+    ExecStartPre=/usr/bin/mount /mnt/music
+
+Now I have already setup my `fstab` to know what to mount on
+`/mnt/music`, but of course that shouldn't be necessary. According to
+the `systemd.service(5)` man page it uses the same syntax as
+`ExecStart`, which tells us that one must use absolute file names
+since no shell is used to start them.
+
+This also has the effect of stopping the `ExecStart` part from the
+`.service` from being executed if the `ExecStartPre` doesn't finish
+successfully. Which works out great in my case as I don't want to
+start `mpd` if my music directory didn't mount. If you want to ignore
+the exit status of (one of) the `ExecStartPre` commands you can prefix
+it with a `-`, for example:
+
+    ExecStartPre=-/usr/bin/mount /mnt/music
+
+Which would continue running the `ExecStart` even if mounting failed.
+
+Also know that there can be multiple `ExecStartPre` options and they
+will be executed serially, so for example:
+
+    ExecStartPre=/usr/bin/mount /mnt/music
+    ExecStartPre=-/usr/bin/mount /mnt/music2
+
+This would fail if `/mnt/music` doesn't mount, but would continue just
+fine if `/mnt/music` did and `/mnt/music2` didn't.

rlwrapping_sbcl.post

@@ -0,0 +1,25 @@
+;;;;;
+title: rlwrapping sbcl
+tags: sbcl, lisp, utility
+date: 2013-10-06 13:02
+format: md
+;;;;;
+
+[SBCL](http://sbcl.org) is an excellent lisp implementation. The only
+thing that's not so nice about it is overly simple command-line
+interface. The absence of `<UP>`, `C-a`, `M-b`, etc. can be annoying,
+even though I only occasionally use SBCL directly.
+
+I have 3 solutions to this problem now:
+
+- Use [SLIME](http://common-lisp.net/project/slime/), which is what I
+  do most of the time, but sometimes this isn't practical.
+
+- Use [Linedit](http://common-lisp.net/project/linedit/). I tried
+  this, and it was cool. But somehow I broke it and now I can't get it
+  to work.
+
+- Use [rlwrap](http://utopia.knoware.nl/~hlub/uck/rlwrap/#rlwrap).
+  This requires you to either always invoke SBCL as `rlwrap sbcl` or
+  create an alias for it. This works very well too, is very simple and
+  doesn't noticeably increase start-up time.

shr-dont-colorize.post

@@ -0,0 +1,30 @@
+;;;;;
+title: Stop shr from using background color
+tags: emacs, elisp, config
+date: 2014-04-03 22:11
+format: md
+;;;;;
+
+Here's just one more example why Emacs is so awesome
+
+Reading mail in Gnus is very nice, but shr has become a little too
+good at its job. Add to this the many occasions when a background is
+specified without specifying a foreground, plus a color theme that
+is the inverse of what is usually expected, and you can get
+hard-to-read HTML messages, gray foreground and gray background.
+
+I've looked at the other possible renderers, but they don't look
+very nice compared to shr. So just remove its ability to add
+background colors.
+
+```emacs-lisp
+(defun oni:shr-colorize-remove-last-arg (args)
+  "If ARGS has more than 3 items, remove the last one."
+  (if (> (length args) 3)
+      (butlast args)
+    args))
+
+(with-eval-after-load 'shr
+  (advice-add #'shr-colorize-region :filter-args
+              #'oni:shr-colorize-remove-last-arg))
+```

some-quick-git-diff-tips.post

@@ -0,0 +1,51 @@
+;;;;;
+title: Some quick git diff tips
+tags: org-mode, lisp, config, git
+date: 2013-08-11 00:54
+format: md
+;;;;;
+
+A couple of quick tips. As you possibly know you can specify some
+options to be used for diffs (and other things) per file type. The one
+I'm interested in is the function name.
+
+## For org-mode
+
+The primary way of identifying which part of an org-mode document a
+change occurs in seems to me to be the heading. So, in your
+`$HOME/.gitconfig` put:
+
+    [diff "org"]
+          xfuncname = "^\\*+.*"
+
+Which should show any lines starting with one or more `*` characters.
+And then in `$XDG_CONFIG_HOME/git/attributes` or
+`$HOME/.config/git/attributes` put:
+
+    ,*.org   diff=org
+
+## For lisp and lisp-like langauges
+
+For anything that resembles lisp (so Common Lisp, Emacs Lisp, Hy,
+scheme, etc.) I would think that the easiest thing to do is just see
+the closes top-level form. So, in your `$HOME/.gitconfig` put:
+
+    [diff "lisp"]
+          xfuncname = "^\\([^ ]+ [^ ]+"
+
+Which should show the opening parenthesis and the first two words. For
+example:
+
+    (defun some-function-name
+    (defclass my-awesome-class
+    (define-route this-strange-route
+
+And then put in your `$XDG_CONFIG_HOME/git/attributes` or
+`$HOME/.config/git/attributes`:
+
+    ,*.lisp  diff=lisp
+    ,*.el    diff=lisp
+    ,*.hy    diff=lisp
+    ,*.scm   diff=lisp
+
+And possibly any other lisp-like language files you can think of.