Initial commit
This commit is contained in:
commit
bada4ecc1a
7 changed files with 357 additions and 0 deletions
68
auto-suggestions-for-duckduckgo-in-conkeror.post
Normal file
68
auto-suggestions-for-duckduckgo-in-conkeror.post
Normal file
|
|
@ -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`.
|
||||||
61
c-d-to-close-eshell.post
Normal file
61
c-d-to-close-eshell.post
Normal file
|
|
@ -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)))
|
||||||
|
```
|
||||||
83
installing-hla-on-archlinux.post
Normal file
83
installing-hla-on-archlinux.post
Normal file
|
|
@ -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.
|
||||||
|
|
||||||
39
mounting-music-dir-before-mpd.post
Normal file
39
mounting-music-dir-before-mpd.post
Normal file
|
|
@ -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.
|
||||||
25
rlwrapping_sbcl.post
Normal file
25
rlwrapping_sbcl.post
Normal file
|
|
@ -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.
|
||||||
30
shr-dont-colorize.post
Normal file
30
shr-dont-colorize.post
Normal file
|
|
@ -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))
|
||||||
|
```
|
||||||
51
some-quick-git-diff-tips.post
Normal file
51
some-quick-git-diff-tips.post
Normal file
|
|
@ -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.
|
||||||
Loading…
Reference in a new issue