Author: grant

Line snippet helper for posting code

On the org list there are a few ways that people post code indicate the start and end of that code. This is my version that might work in any mode:

(defun gcr/insert-noticeable-snip-comment-line ()
  "Insert a noticeable snip comment line (NSCL)."
  (interactive)
  (if (not (bolp))
      (message "I may only insert a NSCL at the beginning of a line.")
    (let ((ncl (make-string 70 ?✂)))
      (newline)
      (previous-line)
      (insert ncl)
      (comment-or-uncomment-region (line-beginning-position) (line-end-position)))))

ADDENDUM: 2014-06-22T10:18:59-0500: Added newline first

Only use in-line footnotes unless your document is very very small

Footnotes in org-mode are really, really great. Before you really get into using them, take a bit of time to think about how you want to use them.
If you have 5 footnotes or less, then don’t think anymore about it. If more then read on.
This topic is not unique to org first of all, it just isn’t something that you consider much until it is too late. Once you get into the org lifecycle, you start tossing and slinging document and code fragments with ease, especially while refactoring. This is all find and well, until you realize that your footnotes will be left sad and alone, abandoned for some cruel fate. In particular, it will break your document.
The better way is to define them all in-line; that will allow simple and easy refactoring in a quite pleasant manner.
Forgot a key point, as I only revisited this today: also generate random IDs. The kind folks in the org community on-list explained this to me. That prevents name collisions. Here is what you need:

(setq org-footnote-define-inline +1)
(setq org-footnote-auto-label 'random)
(setq org-footnote-auto-adjust nil)

ADDENDUM: 2014-06-22T09:07:09-0500
As FUCO1 pointed out, there was something wrong with my approach as I was still using randomly generated IDs. That was my intent. What I wanted was in-line and still reference-able footnote definitions, but without adding them to the Footnote section/heading. After reading the code, I see now the right setting; it was the above plus no auto-adjusting the footnotes. I just updated the code to correct that.

Emacs Lisp programmers must know about pcase

Pattern matching is available in a bunch of programming languages. For some reason, I never thought to look for a library in Emacs Lisp for it, and it is here in pcase.
There is this weird thing that happens when you start using Emacs Lisp. Unlike other languages where you start learning it for “its great features”, most of us only learned it to configure Emacs. Because of this, our brains kind of turn off when it comes to using the language. Or perhaps instead, our expectations change. They are just, lower, and it makes our minds slower. That is why you see so many posts like “if you are programming Emacs Lisp then you must…”.

A faster rsync for Vagrant

[vagrant-gatling-rsync is ] an rsync watcher for Vagrant 1.5.1+ that uses fewer host resources.

How it works:

The built-in rsync-auto plugin sometimes uses a lot of CPU and disk I/O when it starts up on very large rsynced directories. This plugin is designed to work well with such large rsynced folders.
The rsync-auto command that ships with Vagrant 1.5 uses the listen gem. The Listen gem is quite thorough – it uses Celluloid to spin up an actor system and it checks file contents on OS X to ensure that running “touch” on a file (to do a write but not update its content) will not fire the rsync command.
The downside of using Listen is that it takes a large amount of host resources to monitor large directory structures. This gem works well with to monitor directories hierarchies with 10,000-100,000 files.
This gem’s implementation is much closer to the underlying fsevent or inotify APIs, which allows for higher performance.