Tag: Emacs

The Lenticular Text Style of Literate Programming

This announcement is pretty exciting because it reveals a new-to-me take on literate programming. The style is to store a single file as a source, and render disparate parts of that file in different buffers in a mode correct for the content.

For example you may have an Emacs Lisp file serve as the source and two separate buffers, one Emacs Lisp and one Organization (Mode), to work on the content, with all of the mode-specific assistance.

Is it a new idea? It is new to me and I am curious to find out about other approaches people have taken to realize this style.

Here is an overview and a nice video that demonstrates it.

Probably Try to Avoid local-set-key

When I first learned how to set up Emacs, I really liked local-set-key because you didn’t have to know about the keymap for the mode you just had to make the call in that mode’s hook. That is simple and makes total sense. That has worked well for me for years until two things happened:

  • Wanted to use prefix commands
  • Re-started using Windows again on a daily basis

The former is part of the natural expansion of use and its refinement. The latter is similar, but specific to running Emacs on Windows.

The last time that I ran Emacs on Windows I did not use the Super key. Then I went off into the wilderness and use it a lot only to return and find that Windows owns lot of my keybindings. Not only were they owned, but they would not let go of them no matter how I tried! Because if this major inconvenience, I’ve got no reasonable choice other than refactoring some of my perfect bindings into something, ahem, better.

This refactoring would have been pretty easy if I’d jus done normal keybindings against keymaps, but I didn’t, I used local-set-key. So this becomes a good learning opportunity about the key-map names and additionally how, at least for myself, this is generally a bad approach because makes re-factoring harder.

The good thing is that at least up front there is a good time savings, I suppose.

Expanding and Using Abbreviations in Emacs

A defined abbrev is a word which expands, if you insert it, into some different text.

They are really simple and really helpful if you like this kind of thing. If you grew up hacking on Java, then you surely already use this in IntelliJ IDEA!
Here is a nice post on how to choose and define abbrevs based upon actual usage.

Easily check src block correctness in org-mode

Thank you Nicolas Goaziou, for the beginnings of an org-lint. The goal here was to:

  1. Report an error if there is a source block without a language
    specified
  2. Report an error if there is a source block with a language specified
    that is not present in `org-babel-load-languages’

And, it does. 

(defun gcr/src-block-check ()
  (interactive)
  (org-element-map (org-element-parse-buffer 'element) 'src-block
    (lambda (src-block)
      (let ((language (org-element-property :language src-block)))
        (cond ((null language)
               (error "Missing language at position %d"
                      (org-element-property :post-affiliated src-block)))
              ((not (assoc-string language org-babel-load-languages))
               (error "Unknown language at position %d"
                      (org-element-property :post-affiliated src-block)))))))
  (message "Source blocks checked in %s." (buffer-name (buffer-base-buffer))))

Addendum: 2015-02-05
Sebastien Vauban just posted his improved version to:
– “Check as well for the language of inline code blocks,”
– “Report the line number instead of the char position.”

  (defun org-src-block-check ()
    (interactive)
    (org-element-map (org-element-parse-buffer)
      '(src-block inline-src-block)
      (lambda (sb)
        (let ((language (org-element-property :language sb)))
          (cond ((null language)
                 (error "Missing language at line %d in %s"
                        (org-current-line
                         (org-element-property :post-affiliated sb))
                        (buffer-name)))
                ((not (assoc-string language org-babel-load-languages))
                 (error "Unknown language `%s' at line %d in `%s'"
                        language
                        (org-current-line
                         (org-element-property :post-affiliated sb))
                        (buffer-name)))))))
    (message "Source blocks checked in %s." (buffer-name (buffer-base-buffer))))

Not seeing this post on the web yet so no link.

Notes on ALEC

Last week I blogged about pushing ALEC out to GitHub. My focus there was 100% philosophical, and I barely said a thing about the details. This post is to share some of the details.

ALEC is my 5th attempt and configuring Emacs for myself. After spending nearly a year practicing Org-Mode, this version feels much better than the last. The biggest note is that the system compiles in 27 seconds instead of 600 seconds!

The old approach was to generate both a lightweight and heavyweight configuration file, but that is gone now. With a 27s tangle time, you can easily comment out the source block noweb-references to build what you want quite easily.

Package management was the major theme. Cask has worked perfectly, and I wanted to see how easy easily that I could deploy this system on Windows. When I set out to do so, Cask did not have Windows support. Now I think it does, but I’m not going to pursue it right now. Package seems to do quite well, despite some nagging behavior that still exists (noted in the system) of not installing packages sometimes.

The packages are packaged up and stored in GitHub. Heresy? Perhaps. It is a best attempt at capturing the entirety of a working system, so that I and even others have an example or proof that it does what it should be doing.

Literate programming here is done with Org-Mode. It is an insanely delightful and hyper productivity enhancing tool. It is so simple that the 99% will dismiss it as a “markup language”, and the 1% will soon find that the painful-gap between exploration, implementation, and reflection can now be totally and completely removed regardless of the implementation artifact that you use to perform these three critical tasks.