Add blog posts

5 files changed, 246 insertions, 0 deletions

diff --git a/articles/c-d_to_close_eshell.org b/articles/c-d_to_close_eshell.org
new file mode 100644
index 0000000..525e462
--- /dev/null
+++ b/articles/c-d_to_close_eshell.org
@@ -0,0 +1,56 @@
+#+TITLE: C-d to close eshell
+
+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.
+
+#+BEGIN_SRC 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))))))
+#+END_SRC
+
+I then bind this to =C-d= in eshell.
+
+#+BEGIN_SRC emacs-lisp
+  (add-hook 'eshell-mode-hook
+            (lambda () (local-set-key (kbd "C-d") #'eshell-C-d)))
+#+END_SRC
diff --git a/articles/mounting_music_dir_before_mpd.org b/articles/mounting_music_dir_before_mpd.org
new file mode 100644
index 0000000..da9918f
--- /dev/null
+++ b/articles/mounting_music_dir_before_mpd.org
@@ -0,0 +1,44 @@
+#+TITLE:
+#+OPTIONS: toc:nil c:t
+#+HTML_LINK_UP: ../blog.html
+
+* Mounting music dir before MPD                     :systemd:mpd:conf:
+
+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:
+
+#+BEGIN_SRC conf-unix
+  ExecStartPre=/usr/bin/mount /mnt/music
+#+END_SRC
+
+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:
+
+#+BEGIN_SRC conf-unix
+  ExecStartPre=-/usr/bin/mount /mnt/music
+#+END_SRC
+
+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:
+
+#+BEGIN_SRC conf-unix
+  ExecStartPre=/usr/bin/mount /mnt/music
+  ExecStartPre=-/usr/bin/mount /mnt/music2
+#+END_SRC
+
+This would fail if ~/mnt/music~ doesn't mount, but would continue just
+fine if ~/mnt/music~ did and ~/mnt/music2~ didn't.
diff --git a/articles/python-mixins.org b/articles/python-mixins.org
new file mode 100644
index 0000000..2c388f1
--- /dev/null
+++ b/articles/python-mixins.org
@@ -0,0 +1,72 @@
+#+TITLE: Python mixins
+#+TAGS: python,coding
+
+I learned something fun the other day. And it has made me consider
+writing more mixins and using Python's multiple inheritance more. This
+is not completely new to me, but I finally tested it a few days ago
+and what I thought I knew seems to have been confirmed.
+
+Given some classes:
+
+#+NAME: setup
+#+BEGIN_SRC python :exports code :results output :session
+  class Foo(object):
+      def frob(self):
+          print('foo')
+
+
+  class Bar(Foo):
+      def frob(self):
+          super(Bar, self).frob()
+          print('bar')
+
+
+  class BazMixin(object):
+      def frob(self):
+          super(BazMixin, self).frob()
+          print('baz')
+
+
+  class Unmixed(Bar, BazMixin):
+      def frob(self):
+          super(Unmixed, self).frob()
+          print('unmixed')
+
+
+  class Mixed(BazMixin, Bar):
+      def frob(self):
+          super(Mixed, self).frob()
+          print('mixed')
+#+END_SRC
+
+#+RESULTS: setup
+
+We can see the progression of inheritance. You will see here that
+=BazMixin= is skipped:
+
+#+NAME: unmixed
+#+BEGIN_SRC python :exports both :results output :session
+  unmixed = Unmixed()
+  unmixed.frob()
+#+END_SRC
+
+#+RESULTS: unmixed
+:
+: foo
+: bar
+: unmixed
+
+And here that it is not:
+
+#+NAME: mixed
+#+BEGIN_SRC python :exports both :results output :session
+  mixed = Mixed()
+  mixed.frob()
+#+END_SRC
+
+#+RESULTS: mixed
+:
+: foo
+: bar
+: baz
+: mixed
diff --git a/articles/rlwrapping_sbcl.org b/articles/rlwrapping_sbcl.org
new file mode 100644
index 0000000..cc8d94d
--- /dev/null
+++ b/articles/rlwrapping_sbcl.org
@@ -0,0 +1,18 @@
+#+TITLE: rlwrapping sbcl
+
+[[http://sbcl.org][SBCL]] 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 [[http://common-lisp.net/project/slime/][SLIME]], which is what I do most of the time, but sometimes this
+  isn't practical.
+
+- Use [[http://common-lisp.net/project/linedit/][Linedit]]. I tried this, and it was cool. But somehow I broke it
+  and now I can't get it to work.
+
+- Use [[http://utopia.knoware.nl/~hlub/uck/rlwrap/#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/articles/some_quick_git_diff_tips.org b/articles/some_quick_git_diff_tips.org
new file mode 100644
index 0000000..e9d3f39
--- /dev/null
+++ b/articles/some_quick_git_diff_tips.org
@@ -0,0 +1,56 @@
+#+TITLE: Some quick git diff tips
+
+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:
+
+  #+BEGIN_SRC conf
+    [diff "org"]
+          xfuncname = "^\\*+.*"
+  #+END_SRC
+
+  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:
+
+  #+BEGIN_EXAMPLE
+    ,*.org   diff=org
+  #+END_EXAMPLE
+
+* 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:
+
+  #+BEGIN_SRC conf
+    [diff "lisp"]
+          xfuncname = "^\\([^ ]+ [^ ]+"
+  #+END_SRC
+
+  Which should show the opening parenthesis and the first two words.
+  For example:
+
+  #+BEGIN_EXAMPLE
+    (defun some-function-name
+    (defclass my-awesome-class
+    (define-route this-strange-route
+  #+END_EXAMPLE
+
+  And then put in your ~$XDG_CONFIG_HOME/git/attributes~ or
+  ~$HOME/.config/git/attributes~:
+
+  #+BEGIN_EXAMPLE
+    ,*.lisp  diff=lisp
+    ,*.el    diff=lisp
+    ,*.hy    diff=lisp
+    ,*.scm   diff=lisp
+  #+END_EXAMPLE
+
+  And possibly any other lisp-like language files you can think of.