engel

Review: Clojure Programming by Chas Emerick et al.

engel@engel.uk.to (Hans Engel) — Wed, 17 Apr 2013 00:00:00 -0700

I often run into what you might call closet functional programmers – people who seem to have a genuine interest in acquainting themselves with a new paradigm, but just can’t manage to find the time to do it. Some of those who do invest the time often end up on something like the Typeclassopedia¹, where the combined force of jargon and type signatures kill whatever interest they began with.

Thanks to Clojure Programming, though, I’m happy to report that this will no longer be a problem. This book gives hope to those who have championed Lisp and / or functional programming in vain. Emerick et al. provide not only a thorough tour of the language, but also demonstrate the beauty and conciseness of its solutions to common problems. The book dedicates an entire section (“Practicum”) to describing how Clojure is idiomatically used in different application domains.

I was particularly pleased by the stellar coverage of some of Clojure’s most compelling features:

Concurrency primitives (ref, atom, agent, future, and friends)
The power of the JVM and easy Java interop
Lisp syntax (which makes for easy and powerful metaprogramming)
The sequence abstraction

These features are all explained in a bottom-up style (fitting for a Lisp!) – the authors build up a sizeable example by providing an implementation in small increments, explaining along the way. This style is a nice parallel to the nature of traditional Lisp programming.

This book would fit best any of these three groups:

Java refugees. Give me the JVM, hold the AbstractSingletonProxyFactoryBean. Clojure Programming shows you how to take advantage of the vast Java ecosystem while avoiding some of the pitfalls of having static typing and OOP forced upon you. The authors make a good case for interactive programming with the Clojure REPL, which gives you a direct line to the JVM not usually available in Java-land.
Beginning functional programmers. For those already acquainted with a scripting language like Python, Ruby, etc., your first Clojure programs will be a breeze. The book spends a chapter first easing you into Clojure syntax before presenting the basics of functional programming in all of their greatness. You’ll come to love the paradigm and appreciate how Clojure facilitates its use so effectively.
Lispers. While Clojure is by no means a mainstream language, it provides a compelling case of a successful Lisp dialect. The later chapters, which provide examples of Clojure applications in all sorts of distinct domains, will definitely be of interest.

Beginners, intermediate users and masters alike will find something of use in Clojure Programming. It’ll be one of the first books I recommend from now on to anyone curious about Lisp or functional programming.

(Disclosure: I received an electronic copy of this book in exchange for writing a review.)

I’ve absolutely nothing against this document – it’s a fascinating and wonderfully helpful piece of work – but when the first few paragraphs include the words “category theory,” “monoid,” etc., etc., beginners will tend to get spooked!↩

Parsing sound change rules with Parsec: Part 2

engel@engel.uk.to (Hans Engel) — Mon, 17 Dec 2012 00:00:00 -0800

This is the second post in a tutorial series on applying Parsec in historical linguistics. We’ve begun by providing a more formal description of sound change rule grammars and will end by building a full-fledged sound change applier.

In my last post we established a BNF grammar for files which describe sound change rules:

<file>               ::= (<phoneme-class-defn> <EOL>)* (<rule> <EOL>)+
<phoneme-class-defn> ::= <phoneme-class> ":" <phoneme>+
<rule>               ::= <context> ">" <replacement> ["/" <condition>]
<condition>          ::= <context>_<context>
<context>            ::= (<phoneme> | <phoneme-class>)+
<phoneme>            ::= <lowercase-letter>
<phoneme-class>      ::= <uppercase-letter>

Before we begin parsing, let’s set up some basic datatypes which can be used to store the parse results.

import Data.Map (Map)

-- A single phoneme.
type Phoneme = Char

-- Phoneme class storage, mapping from a single character ('V', 'A',
-- 'F', etc.) to a collection of phonemes.
type PhonemeClassMap = Map Char [Phoneme]

-- A string of phonemes used to match a given context.
type Context = [Phoneme]

-- A complete sound change rule.
data Rule = Rule { replacement   :: [Phoneme],
                   beforeContext :: Context,
                   inContext     :: Context,
                   afterContext  :: Context }

instance Show Rule where
    show (Rule r b i a) = show i ++ " > " ++ show r ++ " / " ++ show b
                          ++ "_" ++ show a

Referencing the BNF grammar, we can use these types to build the returns for our parsers. Let’s start with the simplest Parsec rules, anyPhoneme and anyPhonemeClass. Any uppercase character in sound change rules should be interpreted as a phoneme class reference, and any lowercase character must be a phoneme.

import Text.Parsec

anyPhoneme :: Parsec String () Phoneme
anyPhoneme = lower

anyPhonemeClass :: Parsec String () Char
anyPhonemeClass = upper

As evidenced by the given type annotations, our parsers (for the moment) will have a stream type of String, a user state type of (), and a return type that varies based on their purpose.

Our first lift

We need to next build the parser for phoneme class definitions. As a first try, we could have our parser return a pair of type (Char, [Phoneme]), matching with the type of a PhonemeClassMap. Let’s start:

phonemeClassDefinition :: Parsec String () (Char, [Phoneme])
phonemeClassDefinition = (,) (anyPhonemeClass) (many1 anyPhoneme)

This doesn’t work! What gives?

Let’s look at the type of (,), a tuple constructor:

(,) :: a -> b -> (a, b)

And check the type of anyPhonemeClass and many1 anyPhoneme:

anyPhonemeClass  :: ParsecT String () Identity Char
many1 anyPhoneme :: ParsecT String () Identity [Phoneme]

These have the right types Char and [Phoneme], except they’re contained within a ParsecT type.

Good news: ParsecT s u m is a functor! This means that we can “lift” functions into the context defined by the type. Check the type of fmap and fmap (,):

fmap     :: Functor f => (a -> b) -> f a -> f b
fmap (,) :: Functor f => f a -> f (b -> (a, b))

You can check that the type of (,) corresponds with the type of fmap (,). (In fmap’s type signature, b corresponds to b -> (a, b) from (,)’s type.)

Let’s provide fmap (,) with that first argument f a, where f is ParsecT String () Identity and a is Char. (This looks like the type of anyPhonemeClass!)

fmap (,) anyPhonemeClass :: ParsecT String () Identity (b -> (Char, b))

Great - just as fmap’s signature described, (,) was lifted into the ParsecT String () Identity context and a was clarified to be a Char. We can make our expression look a bit nicer by using an infix alias for fmap from Control.Applicative, <$>:

(,) <$> anyPhonemeClass :: ParsecT String () Identity (b -> (Char, b))

Applying within a context

Looking at the types, we’re almost there: we want our final parser to have a return type of (Char, [Phoneme]) and the current parser has a return type of b -> (Char, b). How can we supply a type b?

The answer comes from the fact that ParsecT s u m is not only a functor but an applicative functor. This means that we can apply functions already within the context (like b -> (Char, b)!) to values within the context (like anyPhoneme!).

This contextual application is invoked by Control.Applicative’s <*>. Compare its type with the type of $: the only difference is that <*> operates within a context f.

(<*>) :: Applicative f => f (a -> b) -> f a -> f b
($)   ::                    (a -> b) ->   a ->   b

Let’s apply the lifted and partially applied function from the last section to anyPhoneme:

anyPhoneme :: ParsecT String () Identity Phoneme
(,) <$> anyPhonemeClass :: ParsecT String () Identity (b -> (Char, b))
(,) <$> anyPhonemeClass <*> anyPhoneme
    :: ParsecT String () Identity (Char, Phoneme)

Close: our return type is (Char, Phoneme). Let’s apply with a many1 anyPhoneme instead, which will produce a parser that accepts one or more phonemes.

(,) <$> anyPhonemeClass <*> many1 anyPhoneme
    :: ParsecT String () Identity (Char, [Phoneme])

Great! Our parser returns the proper type. Let’s write the actual implementation of our phoneme class definition rule before continuing:

import Control.Applicative ((<$>), (<*>))

phonemeClassDefinition :: ParsecT String () Identity (Char, [Phoneme])
phonemeClassDefinition = (,) <$> anyPhonemeClass <*> many1 anyPhoneme

We must do a bit of bookkeeping. In the original BNF, we stated that a phoneme class definition was of the form

<phoneme-class-defn> ::= <phoneme-class> ":" <phoneme>+

We need to account for the “useless” colon in this expression. It’s useless in that it contributes nothing to the parse result. Using the *> function from Control.Applicative, we can consume a ':' character and discard its result:

import Control.Applicative ((<$>), (<*>), (*>))

phonemeClassDefinition :: ParsecT String () Identity (Char, [Phoneme])
phonemeClassDefinition :: (,) <$> anyPhonemeClass
                          <*> (char ':' *> many1 anyPhoneme)

Modifying user state

There’s one significant problem left with this parser. True, it eats up strings without a problem:

> parse phonemeClassDefinition "" "V:aeiou"
Right ('V', "aeiou")

Our problem is that we need to reference these definitions in another parser, specifically the context parser:

<context> ::= (<phoneme> | <phoneme-class>)+

Since Parsec has no idea of what a phoneme class is, when we build this parser we’ll need to identify exactly what we should look for in test words given that we saw “V” or “A” in a rule. How can we have the phoneme class definitions “carry over?”

It’s simple using Parsec’s built-in “user state” feature. (It shows up in the u in ParsecT s u m a.) Rather than using () as our user state type, let’s carry along a PhonemeClassMap as state. Each rule’s type needs to now be redefined (but the implementation for those not using the state data need not change):

anyPhoneme :: ParsecT String PhonemeClassMap Identity Phoneme
anyPhonemeClass :: ParsecT String PhonemeClassMap Identity Char
phonemeClassDefinition
    :: ParsecT String PhonemeClassMap Identity (Char, [Phoneme])

In phonemeClassDefinition we’ll need to use Parsec’s modifyState function:

modifyState :: Monad m => (u -> u) -> ParsecT s u m ()

This type annotation does a great job of helping us understand what exactly happens within the function. Given some user state modifier (i.e., a function which takes an old user state of type u and creates a new one), a new parser is yielded which has a user state of type u and returns nothing.

Now phonemeClassDefinition will return nothing and instead modify the parser’s state (i.e., add entries to the phoneme class map).

phonemeClassDefinition :: ParsecT String PhonemeClassMap Identity ()

We want to modify this map by inserting an entry whose contents will be equal . We run into a familiar problem, however, since insert was not built explicitly for use with the ParsecT s u m context:

insert :: a -> b -> Map a b -> Map a b

Let’s lift insert into the ParsecT s u m functor:

(<$>) insert :: (Functor f, Ord a) => f a -> f (a1 -> Map a a1
                                                   -> Map a a1)
insert <$> anyPhonemeClass
    :: ParsecT String PhonemeClassMap Identity (a -> Map Char a
                                                  -> Map Char a)

Close, like before: we can now provide fmap insert with a first argument in the ParsecT s u m context, but the a1 in the type annotation has no concept of context. Using <*> once more, we can fix the problem:

insert <$> anyPhonemeClass <*> (char ':' *> many1 anyPhoneme)
    :: ParsecT String PhonemeClassMap Identity
       (Map Char [Phoneme] -> Map Char [Phoneme])

Before continuing, let’s give a name to the parser created in this section.

modifier :: ParsecT String PhonemeClassMap Identity
            (Map Char [Phoneme] -> Map Char [Phoneme])
modifier = insert <$> anyPhonemeClass <*> many1 anyPhoneme

Notice that Map Char [Phoneme] is equivalent to PhonemeClassMap, or our parser’s user state u. We just did all this work to lift and apply insert within a context, but now, upon revisiting modifyState’s type, we see we’ll need to head in the other direction:

phonemeClassDefinition :: ParsecT String u Identity ()
modifier               :: ParsecT String u Identity (u -> u)
modifyState            :: Monad m => (u -> u) -> ParsecT s u m ()

Binding

If we simplify the types here, the next step should be obvious. (This is pseudo-Haskell.)

u :: PhonemeClassMap
f :: ParsecT String u Identity
a :: u -> u
b :: ()

modifier    :: f a
modifyState :: Monad m => a -> m b

We need some function that, with an f a and a -> f b, derive an f b. This sounds just like >>=, the monadic bind operation!

(>>=)                    :: Monad m => m a -> (a -> m b) -> m b
modifier >>= modifyState :: ParsecT s PhonemeClassMap m ()

That’s it – we’ve found our definition for phonemeClassDefinition! With some reformatting:

phonemeClassDefinition :: ParsecT String PhonemeClassMap Identity ()
phonemeClassDefinition = modifier >>= modifyState
                         where modifier = insert <$> anyPhonemeClass
                                          <*> defn
                               defn     = char ':' >> many1 anyPhoneme

We’ve finished with the hardest parser of the set. In the next post, we’ll tackle the remaining parsers, most of which are simple combinations of those constructed today.

Parsing sound change rules with Parsec: Part 1

engel@engel.uk.to (Hans Engel) — Fri, 14 Dec 2012 00:00:00 -0800

This is the first post in a tutorial series on applying Parsec in historical linguistics. We’ll begin by providing a more formal description of sound change rule grammars and end by building a full-fledged sound change applier.

Historical linguists¹ use a standard grammar to describe a language’s sound change over time (diachronically) or among different speakers at the same time (synchronically). Each individual change can be explained by a simple replacement rule, but often requires a certain context to occur. An example unconditioned sound change rule follows:

r > l

This rule states that, in some language, the /r/ sound becomes /l/ no matter the context of the /r/ sound. This rule alone can effectively describe the change from a morph /fara/ to /fala/, or from /rata/ to /lata/.

Most sound change in natural languages, however, are conditional: they only occur in certain contexts. We can describe required contexts with an additional clause in sound change rules:

r > l / a_o

This rule states that /r/ changes to /l/ only when preceded by an /a/ and succeeded by an /o/. It describes a change from /taro/ to /talo/, but not from /tar/ to /tal/ or /ero/ to /elo/.

We can describe this sound change rule format as a simple BNF grammar:

<rule>          ::= <context> ">" <replacement> ["/" <condition>]
<condition>     ::= <context>_<context>
<context>       ::= (<phoneme> | <phoneme-class>)+
<phoneme>       ::= <lowercase-letter>
<phoneme-class> ::= <uppercase-letter>

Close readers will notice that I included in the above grammar the concept of a phoneme class. Sound change appliers often accept as input along with sound change rules a list of phoneme class definitions. These describe sets of phonemes which, when referenced within a context, allow any of their members to appear in the specified position.

V: aeiou

This line defines a phoneme class V (presumably the vowel class). Whenever V appears in a sound change rule, any of /a/, /e/, /i/, /o/, or /u/ should match.

Phoneme classes are extremely useful, since most sound changes (synchronic and diachronic) only apply in certain phonological contexts rather than standing as a universal fact. Let’s amend our grammar so that we can describe an entire sound change collection:

<file>               ::= (<phoneme-class-defn> <EOL>)* (<rule> <EOL>)+
<phoneme-class-defn> ::= <phoneme-class> ":" <phoneme>+
<rule>               ::= <context> ">" <replacement> ["/" <condition>]
<condition>          ::= <context>_<context>
<context>            ::= (<phoneme> | <phoneme-class>)+
<phoneme>            ::= <lowercase-letter>
<phoneme-class>      ::= <uppercase-letter>

In the next installment of this tutorial, we’ll use this grammar to build a Parsec parser that can digest sound change rules.

And conlangers!↩

Hillis β-reduction in Haskell

engel@engel.uk.to (Hans Engel) — Sun, 26 Aug 2012 00:00:00 -0700

I decided to rewrite my Hillis β-reduction routine in Haskell. I was very pleased to find that the rewrite yielded code much more concise and less “hacky” than the original Clojure algorithm.¹

module Beta (beta)
where

import Data.Map (Map, alter, empty)

-- Used to insert or merge map values. Partially apply this function
-- with a merge function and an initial value, then use it in
-- `Data.Map.alter`.
alterer :: (a -> a -> a) -> a -> Maybe a -> Maybe a
alterer _ v Nothing = Just v
alterer f v (Just x) = Just (f v x)

-- beta-reduce a list of keys and values with a given merge function.
beta :: Ord k => (a -> a -> a) -> [k] -> [a] -> (Map k a)
beta f keys vals = beta' empty f keys vals

-- Internal recursive function.
beta' :: Ord k => (Map k a) -> (a -> a -> a) -> [k] -> [a] -> (Map k a)
beta' map _ [] _ = map
beta' map _ _ [] = map
beta' map f (k:ks) (v:vs) = let map' = alter (alterer f v) k map
                            in beta' map' f ks vs

Data.Map turned out to be a lifesaver!↩

Hillis beta reduction improvements

engel@engel.uk.to (Hans Engel) — Sun, 08 Jul 2012 00:00:00 -0700

Last week I introduced the concept of Hillis beta reduction and provided an example implementation in Clojure. There were a few caveats to this implementation, however, mostly stemming from the fact that I β-reduced with sequences and vectors rather than the native “xectors” of Hillis’ system. With the risk of adding even more complexity to the demonstration, I’d like to attempt to rectify some of these problems using a few extra tools to transform our data.

Xectors

I won’t provide much detail at all on the xector data type, as I will inevitably botch the majority of the facts. If you’re at all interested in parallel computing, I recommend checking out Hillis’ book, The Connection Machine.

For our purposes, we can consider a xector to be equivalent to a Clojure map¹. We can easily redesign our Hillis β-reduction function to take maps as input, but who would want to convert a sequence to a map whenever using the function?

The Xector monad

For this issue we can design a small monad which deliberately breaks the monad laws (cowboy monad?) for demonstration purposes². The monad will convert provided seqs into an internal map (xector) representation for use in the β-function and (here’s the law-breaking part) leave them as maps when returning results. We could be proper and return the same seq type that was provided, but that would essentially destroy the purpose of the β-reduction in the first place!

Without further ado:

(use 'clojure.algo.monads)
(defmonad xector-m
  [;; Xector a -> a
   m-result (fn m-result-xector [xector]
              (if (= 1 (count xector))
                (first (vals xector))
                xector))

   ;; a -> (Xector b -> Xector c) -> Xector c
   m-bind (fn m-bind-xector [v f]
            (let [xec (if (sequential? v)
                        (into {} (map-indexed vector v))
                        v)]
              (f xector)))])

Notice the cheating in m-result: we return constant values as expected, but non-constant values (i.e., maps made from seqs) are kept as maps.

In m-bind, we convert any type of seq into a map, and keep any other constant value (in our case, we’ll use numbers) unmodified³.

β-reduction-redux

We define a new multimethod xvals which dispatches on the result of map?⁴. This aligns with the result of the monad bind we defined earlier: for any a of Xector a, a will be either a map or a constant.

(defmulti xvals map?)
(defmethod xvals true [xec] (vals xec))
(defmethod xvals false [const] (repeat const))

(defn beta
  ;; (a -> b) -> Xector c -> Xector d
  ([f x1]
     (beta f x1 1))
  ;; (a -> b) -> Xector c -> Xector d -> Xector e
  ([f x1 x2]
     (let [c1 (xvals x1)
           c2 (xvals x2)]
       (loop [acc {}
              e1 (first c1) c1 (rest c1)
              e2 (first c2) c2 (rest c2)]
         (if (or (nil? e1) (nil? e2))
           acc
           (let [new-val (if (contains? acc e2)
                           (f (get acc e2) e1)
                           e1)]
             (recur (assoc acc e2 new-val)
                    (first c1) (rest c1)
                    (first c2) (rest c2))))))))

Now we can perform β-reduction on seqs by binding them inside our xector-m:

(domonad xector-m
         [a '(1 2 5)
          b '(X Z Z)]
         (beta + a b))  ; => {X 1, Z 7}

Traditional folds can now return the expected values without a wrapping map:

(domonad xector-m
         [a '(1 2 5)
          b 1]
         (beta + a b))  ; => 8

Hillis’ arity function

Now that we have a better-ported version of the beta function, I can present a fascinating application also imagined by Hillis later in his paper. It uses both the one- and two-argument forms of the beta function: it simultaneously folds multiple maps into a single map, and then folds that single map to a single value. As always, the code speaks more clearly than I can:

;; Return the highest arity of the sequence (i.e., the number of times
;; the most often occurring element appears).
(defn arity [seq]
  (domonad xector-m
           [a 1
            b seq]
           (beta max (beta + a b))))

In the inner β-reduce, we reduce a set of keys to the same constant value of 1. When duplicate keys (duplicate occurrences of a value in the provided seq) are found, the value 1 is combined with another value 1 using the function +, forming a count of 2! This process repeats until the entire provided seq has been digested. Here’s a look at the inner β-reduction by itself (notice that its output matches that of frequencies!):

(domonad xector-m
         [a 1
          b '(2 3 8 2 2 5 8 2)]
         (beta + a b))  ; => {2 4, 3 1, 5 1, 8 2}

Where from here?

To be frank: not a clue! I am having trouble thinking of names for the process, let alone applications. It will most likely remain nothing more than a “thought experiment,” as I said in my previous post. Let me know in the comments below if you have any thoughts!

Ignoring all the parallel-processing fun that comes along with xectors, yes.↩
I still don’t fully understand monads, so I may actually be breaking more laws than I intend.↩
I experimented with a ConstantXector type and a :constant metadata key, but both of these methods proved much less elegant than simply leaving the value alone.↩
Dispatches on “mappiness?”↩

Hillis beta reduction in Clojure

engel@engel.uk.to (Hans Engel) — Tue, 03 Jul 2012 00:00:00 -0700

Danny Hillis’ seminal work The Connection Machine introduced, among many other things, the concept of “beta reduction” on vectors¹ (I dub this “Hillis beta reduction” so as not to confuse the term with traditional beta reduction in the lambda calculus). I found this particular idea fascinating and still applicable today, if only as a quick thought experiment.

Hillis asserted that the everyday fold / reduce routines that we have all come to know and love are merely a subset of a larger scheme of operations that can be performed on ordered data structures. The overarching process is named the “beta function,” and accepts one function and two vectors as arguments. The result of this function is the combination of the two vectors into a map, using the first vector to form the map’s values and the second vector to form the map’s keys. When duplicate keys are found, the provided function is used to “combine” the corresponding values. It’s an interesting process that’s much easier to understand given an example:

(beta + '(1 2 5) '(X Z Z))  ; => {X 1, Z 7}

Using the positions of each element to match keys and values of the map to be formed, the beta function pulls together data like a zip function. When the duplicate key Z is encountered twice, the two values are combined using the + function we provided, and the final value corresponding to the key Z in the map is (+ 2 5), or 7.

What is traditional list folding, then? Why, it’s just beta reduction with a certain constant second argument:

(beta + '(1 2 5) (repeat 1))  ; => {1 8}

When we provide the beta function with the same key for every value (1, in this case), all values are combined to the same key using the provided function. This is reduction in a different form!²

Below is an implementation of Hillis’ beta function in Clojure. I included a shorthand form of the function in which a two-argument call will give the same result as a call to reduce:

(beta + '(1 2 5))  ; => 8

Feel free to play around!

(defn beta
  ([f c1]
     (get (beta f c1 (repeat 1)) 1))
  ([f c1 c2]
     (loop [acc {}
            e1 (first c1) c1 (rest c1)
            e2 (first c2) c2 (rest c2)]
       (if (or (nil? e1) (nil? e2))
         acc
         (let [new-val (if (contains? acc e2)
                         (f (get acc e2) e1)
                         e1)]
           (recur (assoc acc e2 new-val)
                  (first c1) (rest c1)
                  (first c2) (rest c2)))))))

For simplicity’s sake, I deliberately ripped out Hillis’ concept of beta reduction from its containing system of parallel processing with xectors. References to this particular domain have been shamelessly replaced with Clojure-specific terms.↩
You may notice that this alternate fold returns {1 8} rather than a simple 8. This is due to my somewhat-haphazard readaptation of Hillis’ concept for Clojure: the {1 8} that is returned is technically correct within Hillis’ system of xectors, but is not convenient for those of us living in a von Neumann world. I experimented in using a xector monad as a sort of shim to better integrate beta-reduction into Clojure, but did not develop it far enough to make it merit more than a mention in a footnote.↩

Disabling electric indenting in Emacs modes

engel@engel.uk.to (Hans Engel) — Mon, 02 Jul 2012 00:00:00 -0700

I am just getting settled in with Org Mode for Emacs and am constantly amazed at its versatility and wide feature set. One problem has been bugging me in Org for quite a while now, though: electric-indent-mode, which I use for auto-indentation when programming, gets in the way by auto-indenting Org headers.

My annoyance reached a critical point earlier this morning, and so I set off in search of a fix to disable electric indenting “mode-locally” — that is, disable the mode in Org buffers but not in buffers of any other mode. The catch with electric-indent-mode is that it is a global minor mode — something that is enabled once and assumed to be necessary for all buffers.

After a bit of searching, however, I was glad to find that the author of the mode had left in a backdoor for customizing its functionality. Meet electric-indent-functions:

Special hook run to decide whether to auto-indent. Each function is called with one argument (the inserted char), with point right after that char, and it should return t to cause indentation, `no-indent’ to prevent indentation or nil to let other functions decide.

Perfect! The default value for this variable (as of Emacs 24.0.92.1) is nil, so I made the choice to recklessly overwrite this variable at a buffer-local level.

Enough technoblabber; here’s the fix. Add the following code into an Emacs Lisp file that gets run on initialization:

(add-hook 'org-mode-hook
          (lambda ()
            (set (make-local-variable 'electric-indent-functions)
                 (list (lambda (arg) 'no-indent)))))

You can find the latest version of my Org mode config in my dotfiles repo.

Post excerpts in Jekyll

engel@engel.uk.to (Hans Engel) — Sat, 21 Jan 2012 00:00:00 -0800

There’s a fairly simple method for creating WordPress-like post excerpts in Jekyll using a  tag, but unfortunately it requires the installation of a Jekyll plugin, a feature unavailable on a GitHub-hosted Jekyll instance.

What’s a bored geek like me to do? Find another way! The exact same excerpt functionality linked to earlier can be replicated by composing a few Liquid filters in the site layout code, like so:

{{ post.content | split: '<!-- more -->' | first }}

This little bit of code will output the content of a post until it sees a  tag inside the post content. Just insert the  tag into your posts wherever you’d like them to be cut off.

You can see this snippet in action in my site index template.