commit bada4ecc1a09a3e4a98ae3449f6e6e7e6de19fef Author: Tom Willemse Date: Fri Jan 2 03:40:45 2015 +0100 Initial commit diff --git a/auto-suggestions-for-duckduckgo-in-conkeror.post b/auto-suggestions-for-duckduckgo-in-conkeror.post new file mode 100644 index 0000000..429918c --- /dev/null +++ b/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[1](#fn1) with the newly downloaded one and you'd be +done, ready to use the new auto-suggest +functionality[2](#fn2). + +If, however, you don't like overwriting your package's files because +they may get overwritten again in the future[3](#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[4](#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 + + I have Conkeror installed in `/usr`, so if you have +it installed somewhere else your path will be different. + + You might have to restart Conkeror first, I didn't +test it without restarting. + + This can of course happen when, for example, your +package manager updates your Conkeror installation. + + The default profile is named (appropriately) +`default`. diff --git a/c-d-to-close-eshell.post b/c-d-to-close-eshell.post new file mode 100644 index 0000000..fca531f --- /dev/null +++ b/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))) +``` diff --git a/installing-hla-on-archlinux.post b/installing-hla-on-archlinux.post new file mode 100644 index 0000000..17826c8 --- /dev/null +++ b/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 <`, `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. diff --git a/shr-dont-colorize.post b/shr-dont-colorize.post new file mode 100644 index 0000000..044a29a --- /dev/null +++ b/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)) +``` diff --git a/some-quick-git-diff-tips.post b/some-quick-git-diff-tips.post new file mode 100644 index 0000000..12a728d --- /dev/null +++ b/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.