Irreal: Micro-Habit Video

If you liked Sacha Chua's post on micro-habits that I wrote about yesterday, be sure to check out her video on the same subject. In it, she discusses various packages for switching windows and for jumping around in a buffer or even multiple buffers.

She also discusses how she leverages the key-chord package to invoke her window switching and buffer navigation. You don't have to worry about trying to remember her configuration because it's available online in an excellent literate programming Org file. Watch the video and get any specifics you need from her configuration file.

The video is just over eight and a half minutes so it should be easy to fit a viewing into your schedule. As always with Chua, your time will be well spent.

-1:-- Micro-Habit Video (Post jcs)--L0--C0--January 26, 2015 12:12 PM

Oleh Krehel: occur-dwim (Do What I Mean)

I'd like to share a little snippet that I like to use instead of a plain M-s o (occur).


(defun occur-dwim ()
  "Call `occur' with a sane default."
  (push (if (region-active-p)
          (thing-at-point 'symbol))
  (call-interactively 'occur))

It will offer as the default candidate:

  • the current region, if it's active
  • the current symbol, otherwise

It's pretty good, since I actually want the default candidate in 95% of the cases. Some other functions, such as rgrep are smart like this out-of-the-box.

A Hydra that goes nicely with occur

Since occur, like some other functions (grep, rgrep, compile), works with next-error, it's possible to use this Hydra to navigate the occur matches:

(hydra-create "M-g"
  '(("h" first-error "first")
    ("j" next-error "next")
    ("k" previous-error "prev")))

Hydra was introduced in an earlier post, and is available in GNU ELPA.

What goes around comes around

I usually do a quick internet search to see where I got the code that I'm posting here, reason being that it's nice to list the source, as well as there could be more advanced stuff out there on the same topic.

I saw a few results for "occur-dwim" so I thought that I just copy-pasted it from somewhere. Slight disappointment turned into a small sense of pride, when I found that the source of the copy-pastes was my old Stack Overflow answer:)

-1:-- occur-dwim (Do What I Mean) (Post)--L0--C0--January 25, 2015 11:00 PM

Grant Rettke: A reference card for code execution in org 8

refcard-org-babel “contains the reference documentation that describes how to perform code execution within Org mode documents using Org Babel 8″.

Look forward to referencing this when I read about other’s personal org workflows, and, document down my own.

-1:-- A reference card for code execution in org 8 (Post Grant)--L0--C0--January 25, 2015 09:56 PM

Irreal: Sacha on Emacs Micro-Habits

Sacha Chua, as everyone here knows, is relentless about improving her work flow and procedures. Happily for us, she's also diligent about sharing the results of her efforts with the rest of us. Her recent outstanding post on cultivating Emacs micro-habits is an excellent example of this.

She's thought more deeply than most of us about which habits make sense and are worth the effort to burn into our muscle memory. The post represents some of her conclusions so far. Even if you're an experienced Emacs user, you are likely to find something useful in the post that you didn't know.

For example, she has a nice idiom for dealing with the problem of writing commands that work on the entire buffer unless a region is defined. I've long used a macro for that but Chua has another way. Suppose we want to extract the contents of a buffer into a string unless a region is defined, in which case we want the contents of just the region. Chua uses conditon-case like this:

(setq contents (condition-case nil (buffer-substring beg end) (mark-inactive (buffer-string))))

That's not a micro-optimization in itself but is part of a function that copies code into a blog post, posts it as a Gist, and adds a link to the Gist in the blog post. That's something useful too if you post code as a Gist.

Another nice trick I learned is how to programmatically retrieve properties from an Org mode buffer. That's also very useful if you want to write code to automatically process an Org buffer.

The whole post is full of goodness and you really should give it a read. If you're interested in improving your work flow, you'll probably find something useful.

-1:-- Sacha on Emacs Micro-Habits (Post jcs)--L0--C0--January 25, 2015 04:15 PM

Giorgos Keramidas: Some Useful RCIRC Snippets

I have started using rcirc as my main IRC client for a while now, and I really like the simplicity of its configuration. All of my important IRC options now fit in a couple of screens of text.

All the rcirc configuration options are wrapped in an eval-after-load form, to make sure that rcirc settings are there when I need them, but they do not normally cause delays during the startup of all Emacs instances I may spawn:

(eval-after-load "rcirc"


     (message "rcirc has been configured.")))

The “rcirc-setup-forms” are then separated in three clearly separated sections:

  • Generic rcirc configuration
  • A hook for setting up nice defaults in rcirc buffers
  • Custom rcirc commands/aliases

Only the first set of options is really required. Rcirc can still function as an IRC client without the rest of them. The rest is there mostly for convenience, and to avoid typing the same setup commands more than once.

The generic options I have set locally are just a handful of settings to set my name and nickname, to enable logging, to let rcirc authenticate to NickServ, and to tweak a few UI details. All this fits nicely in 21 lines of elisp:

;; Identification for IRC server connections
(setq rcirc-default-user-name "keramida"
      rcirc-default-nick      "keramida"
      rcirc-default-full-name "Giorgos Keramidas")

;; Enable automatic authentication with rcirc-authinfo keys.
(setq rcirc-auto-authenticate-flag t)

;; Enable logging support by default.
(setq rcirc-log-flag      t
      rcirc-log-directory (expand-file-name "irclogs" (getenv "HOME")))

;; Passwords for auto-identifying to nickserv and bitlbee.
(setq rcirc-authinfo '(("freenode"  nickserv "keramida"   "********")
                       ("grnet"     nickserv "keramida"   "********")))

;; Some UI options which I like better than the defaults.
(rcirc-track-minor-mode 1)
(setq rcirc-prompt      "»» "
      rcirc-time-format "%H:%M "
      rcirc-fill-flag   nil)

The next section of my rcirc setup is a small hook function which tweaks rcirc settings separately for each buffer (both channel buffers and private-message buffers):

(defun keramida/rcirc-mode-setup ()
  "Sets things up for channel and query buffers spawned by rcirc."
  ;; rcirc-omit-mode always *toggles*, so we first 'disable' it
  ;; and then let the function toggle it *and* set things up.
  (setq rcirc-omit-mode nil)
  (set (make-local-variable 'scroll-conservatively) 8192))

(add-hook 'rcirc-mode-hook 'keramida/rcirc-mode-setup)

Finally, the largest section of them all contains definitions for some custom commands and short-hand aliases for stuff I use all the time. First come a few handy aliases for talking to ChanServ, NickServ and MemoServ. Instead of typing /quote nickserv help foo, it’s nice to be able to just type /ns help foo. This is exactly what the following three tiny forms enable, by letting rcirc know that “/cs”, “/ms” and “/ns” are valid commands and passing-along any arguments to the appropriate IRC command:

;; Handy aliases for talking to ChanServ, MemoServ and NickServ.

(defun-rcirc-command cs (arg)
  "Send a private message to the ChanServ service."
  (rcirc-send-string process (concat "CHANSERV " arg)))

(defun-rcirc-command ms (arg)
  "Send a private message to the MemoServ service."
  (rcirc-send-string process (concat "MEMOSERV " arg)))

(defun-rcirc-command ns (arg)
  "Send a private message to the NickServ service."
  (rcirc-send-string process (concat "NICKSERV " arg)))

Next comes a nifty little /join replacement which can join multiple channels at once, as long as their names are separated by spaces, commas or semicolons. To make its code more readable, it’s split into 3 little functions: rcirc-trim-string removes leading and trailing whitespace from a string, rcirc-normalize-channel-name prepends “#” to a string if it doesn’t have one already, and finally rcirc-cmd-j uses the first two functions to do the interesting bits:

(defun rcirc-trim-string (string)
  "Trim leading and trailing whitespace from a string."
  (replace-regexp-in-string "^[[:space:]]*\\|[[:space:]]*$" "" string))

(defun rcirc-normalize-channel-name (name)
  "Normalize an IRC channel name. Trim surrounding
whitespace, and if it doesn't start with a ?# character, prepend
one ourselves."
  (let ((trimmed (rcirc-trim-string name)))
    (if (= ?# (aref trimmed 0))
      (concat "#" trimmed))))

;; /j CHANNEL[{ ,;}CHANNEL{ ,;}CHANNEL] - join multiple channels at once
(defun-rcirc-command j (arg)
  "Short-hand for joining a channel by typing /J channel,channel2,channel,...

Spaces, commas and semicolons are treated as channel name
separators, so that all the following are equivalent commands at
the rcirc prompt:

    /j demo;foo;test
    /j demo,foo,test
    /j demo foo test"
  (let* ((channels (mapcar 'rcirc-normalize-channel-name
                           (split-string (rcirc-trim-string arg) " ,;"))))
    (rcirc-join-channels process channels)))

The last short-hand command lets me type /wii NICK to get “extended” whois information for a nickname, which usually includes idle times too:

;; /WII nickname -> /WHOIS nickname nickname
(defun-rcirc-command wii (arg)
  "Show extended WHOIS information for one or more nicknames."
  (dolist (nickname (split-string arg " ,"))
    (rcirc-send-string process (concat "WHOIS " nickname " " nickname))))

With that, my rcirc setup is complete (at least in the sense that I can use it to chat with my IRC friends). There are no fancy bells and whistles like DCC file transfers, or fancy color parsing, and similar things, but I don’t need all that. I just need a simple, fast, pretty IRC client, and that’s exactly what I have now.

Filed under: Computers, Emacs, Free software, Open source, rcirc, Software Tagged: Computers, Emacs, Free software, Open source, rcirc, Software
-1:-- Some Useful RCIRC Snippets (Post keramida)--L0--C0--January 25, 2015 08:41 AM

Oleh Krehel: Exploring Emacs packages

Currently, MELPA hosts over 2250 packages. That's quite a large number, although it's still feasible to try most of the popular ones. In comparison,

apt-cache pkgnames | wc

gives me the number 50250. I don't recall calling apt-cache pkgnames ever before, while I call package-list-packages all the time. I suppose that this will have to change when the number of packages grows further.

I usually explore packages just as they show up as new in package-list-packages. I'll share the two tools that I use for exploring them.


Smex is an M-x enhancement for Emacs. In addition to executing commands faster, it gives you an option to jump to the current command's definition with M-..

Here's how I bind smex:

(require 'smex)
(global-set-key "\C-t" 'smex)
(defun smex-prepare-ido-bindings ()
  (define-key ido-completion-map
      (kbd "C-,") 'smex-describe-function)
  (define-key ido-completion-map
      (kbd "C-w") 'smex-where-is)
  (define-key ido-completion-map
      (kbd "C-.") 'smex-find-function)
  (define-key ido-completion-map
      (kbd "C-a") 'move-beginning-of-line)
  ;; (define-key ido-completion-map "\C-i" 'smex-helm)
  ;; (define-key ido-completion-map " " 'smex-helm)

I don't feel bad at all for unbinding transpose-chars, C-t is such a prime binding, that only the best commands can deserve it. And since I touch-type, it's easier for me to hit M-DEL and retype the word when I notice a mistake, than to carefully navigate to the mistake location and call transpose-chars with surgical precision. On the other hand, the number of Emacs packages is only going to grow, so it becomes less and less feasible to bind everything. Instead, seldom used stuff can be called though smex. For instance, I don't bind markdown-toc or speed-type and call them via C-t instead.

Back to the point, C-t ... C-. (smex-find-function) allows me to quickly jump to the source of the package that I want to explore.

Semantic tags

Once I'm in the source code, I can quickly get an overview with g (lispy-goto) from lispy. It uses CEDET's semantic module to get a list of tags in current directory with helm for completion. In my opinion, it's much prettier than helm's own helm-semantic. It also explores more tags for Emacs Lisp, for instance it will capture use-package and global-set-key tags.

A new cute feature that I added recently is a different background for user-visible functions, i.e. the ones that are callable by M-x or smex. Here's how it looks like, for the speed-type package (interactive functions have a purple background):


If the image text looks too small, you can right click / view image in your browser. Here, I can see at a glance, that there are three commands that I can call. I can also see a few variables, two of them don't include --, so they're probably customizable.

-1:-- Exploring Emacs packages (Post)--L0--C0--January 24, 2015 11:00 PM

Thomas Fitzsimmons: Emacs and TWiki

At work I have cause to edit a TWiki that my team uses for internal documentation. I wanted to use Emacs for this task, so that I wouldn’t need to interact with a web browser text area widget. I couldn’t find anything that did that, so I took the closest thing I could find, erin.el, a TWiki markup mode, and added connectivity to it via Emacs’s url package.

The result is a fork of erin.el that supports these new operations:

Log in: M-x erin-log-in
Edit a topic: M-x erin-edit-topic
Commit edits: C-c C-c
Cancel edits: C-c C-k
Log out: M-x erin-log-out

without ever leaving Emacs. Now with EWW to see the resulting pages, there’s no need to leave Emacs at all.

This being a fork, it doesn’t qualify for MELPA, and I can’t get in touch with the original author, so it will stay in limbo as a raw repo, without ever being packaged.

A while after I did this development, emacs-twiki-mode sprang up. It looks like it has some nice advantages, like orgtbl editing. If it used Emacs’s built-in URL handling instead of an external bash script I would probably switch to it. For now my erin.el fork works well enough for me. I do wish there were one monster Emacs mode that would handle all Wiki server implementations, including connectivity; a sort of Gnus for Wikis. Oh well.

-1:-- Emacs and TWiki (Post Thomas Fitzsimmons)--L0--C0--January 23, 2015 05:05 AM

Kunigami: Coloring emacs active pane

When working using multi-panes within emacs, I often lose track of which pane my cursor is on.

There’s a very easy way to customize emacs to color panes differently based on whether they are active:

-1:-- Coloring emacs active pane (Post kunigami)--L0--C0--January 21, 2015 07:46 PM

sachachua: Developing Emacs micro-habits: Abbreviations and templates

When it comes to improving how you use Emacs, picking one small change and paying close attention seems to work well. Little things make a lot of difference, especially when frequently repeated over a long period of time. It reminded me of this quote I came across on Irreal:

I’ve gotten the hang of basic multiple-cursors-mode and I’m making gradual progress towards internalizing smart-parens by the simple approach of focusing on one tiny habit at a time. For example, I spent a week reminding myself to use mc/mark-all-like-this-dwim or mc/mark-lines instead of using keyboard macros.

Inspired by the Emacs Advent Calendar, I wanted to start a 52-week series on micro-habits for more effective Emacs use. I brain-dumped an outline of four sets (basic Emacs, Org, programming, meta-habits) of thirteen small tips each. Looking at my list, I realized there were many ideas there that I hadn’t quite gotten the hang of myself. I figured that this might be more of a project for 2016; in the meantime, I could learn by doing.

The first micro-habit I wanted to dig into was that of automating text: abbreviations, templates, and other ways to expand or transform text. I’d used Yasnippet before. I sometimes accidentally expanded keywords instead of indenting lines if my cursor happened to be at the wrong spot. But I hadn’t yet drilled the instinct of automation or the familiarity with templates into my fingers.

This blog post isn’t the easy-to-understand guide to automating text. I’ll write that later, when I’ve figured more things out. In the meantime, I’ll share what I’ve been learning and thinking so far, and maybe you can help me make sense of it.

Emacs has a separate manual for autotyping, which I had never read before. The short manual covers abbrev, skeleton, auto-insert, copyright messages, timestamps, and tempo. Did you know that define-skeleton lets you create a template that accepts multiple interregions if you call your skeleton function with a negative argument? (Interregions? What are those?) It took me an embarrassing amount of time to figure out how to mark interregions and use them. It turns out they have to be contiguous. It might be easier to think of marking the beginning of the region, marking some points in the middle, and then calling the command when your point is at the end – which is probably how most people would interpret the diagrams, but I was trying to mark discontinuous regions because that would be super-cool, and that totally didn’t work. And then I forgot that using helm-M-x means you need to specify numeric arguments after typing M-x instead of before. (I wrote about that very point in one of my blog posts, but it slipped my mind.) Once I got past that, I was delighted to find that it worked as advertised. I still haven’t imagined a situation where I would use it, but it seems like a good sort of thing to know.

What are the practical situations where text automation can help people work more effectively? I looked around to see how other people were using it. Coding, of course – especially if you use Emacs Lisp to transform the text. Debugging, too. Marking up text. Remembering parameters. Wrapping regions. Writing e-mails. Adding blog post metadata. Citing references. Lifehacker has a long list, too.

I came up with several categories I’m going to focus on so that I can more easily recognize opportunities to work better:

2015-01-05 Seeing opportunities for abbreviations and text automation -- index card

2015.01.05 Seeing opportunities for abbreviations and text automation – index card

  • Abbreviations are about typing long words with fewer keystrokes. For example, you might shorten “description” to desc.
  • Phrases are like word abbrevations, but longer. You might want to be able to expand btw to “by the way.”
  • Code benefits from expansion in multiple ways:
    • Automatically inserting characters that are harder to reach on a keyboard, like { and }
    • Being consistent about coding style, like the way many people like adding a comment after the closing brace of an if
    • Transforming text that shows up in multiple places, such as variable names that need getters and setters
    • Filling in the blanks: parameters, comments, etc.
    • Reducing the cognitive load of switching between languages by establishingq a common vocabulary. For example, I sometimes need to look up the syntax of for or the proper way to display a debugging statement when I switch to a language I haven’t used in a while
  • Templates are also useful for consistency in writing, planning, and other areas
  • Text transformation can save time and minimize error.

2015-01-04 Automating text - index card

2015.01.04 Automating text – index card

Translating the examples I’d seen to my personal interests, I could probably find plenty of opportunities to automate text while coding, debugging, writing, planning, or publishing. To dig deeper, I looked at each of the categories in detail.


2015-01-06 Abbreviations -- index card

2015.01.06 Abbreviations – index card

When I was curious about typing faster, I read forum posts from people who had increased their speed by developing their own form of digital shorthand. The trick works on paper, too. When I need to write quickly or in limited space, I use abbreviations like bc for “because” and w/o for “without.” Why not on the computer as well?

I often take advantage of dynamic abbreviations when I know I’ve recently typed the word I want. To trigger those, I just have to type the beginning of the word and then use dabbrev-expand. I haven’t set up my own static abbreviations, though. Main obstacles:

  • I want to write shorter words instead of longer ones
  • In the beginning, it’s faster to type the word instead of thinking of the abbreviation and expanding it
  • If I have to undo or backspace, that makes me slower
  • If I burn this into my muscle memory, I might be more frustrated on other computers or in other apps (then again, I already customize Emacs extensively, so I guess I’m okay with the tradeoff)

Anyway, here’s a short list I’m trying out with define-global-abbrev and hippie-expand:

hw however
bc because
wo without
prob probably
st sometimes

Hmm. Let’s say that it takes me two keystrokes to trigger the expansion, whether it’s the xx keychord I’ve just set up or the M-/ I’ve replaced with hippie-expand. (Hmm, maybe a double-space keychord is a good candidate for expansion too.) Is the retraining worth a ~50% possible reduction in keystrokes? Probably not.

How about text with punctuation, so I can minimize reaching for symbols?


Maybe it’s better to look at the words I frequently misspell, or that I tend to slow down then typing. I’ll keep an eye out for those.


2015-01-06 Phrases -- index card

2015.01.06 Phrases – index card

Phrases are an easier sell. Still, I’m trying not to settle into the rut of set phrases. I should cut those mercilessly or avoid writing them from the beginning.

co check out
iti I think I
otoh on the other hand,
mean in the meantime,
fe for example
fi for instance,
oc of course
ip in particular

Code insertion

This is, fortunately, well-trodden ground. The yasnippet package comes with a large collection of snippets for many programming languages. You can start by familiarizing yourself with the pre-defined snippets for the modes that you use. For example, in my installation, they’re under ~/.emacs.d/elpa/yasnippet-20141117.327/snippets. You can use the filename (or keywords defined with key, if specified) as the abbreviation, and you can expand them with yas-expand (which should be bound to TAB if you have yas-global-mode on).

I mostly work with HTML, CSS, Javascript, Ruby on Rails, and Emacs Lisp, so this is the cheat sheet I’ve made for myself:

2015-01-07 Code insertion -- index card

2015.01.07 Code insertion – index card

For HTML, I need to remember that the tags are generally expandable, and that there are a few Lorem Ipsum abbreviations triggered by lorem.1 through .5. CSS has a v abbreviation that sets up a bunch of rules with vendor prefixes. For Javascript, I’ll probably start with f to define a function and log to output something to console.log. Rails has a bunch of iterators like eai that look interesting. As for Emacs Lisp, the pre-defined templates generally add parentheses around common functions so you don’t have to type them, and there are a few shortcuts like bs for buffer-string and cc for condition-case. I think I’ll modify the default snippets to make better use of Yasnippet’s field support, though, so that I don’t have to delete and replace text.


In addition to using text expansion for code, you can use it for planning and writing other text. I saw Karl Voit use it to great effect in my Emacs Chat with him (around the 44:00 mark), and I’ve been gradually refining some templates of my own.

2015-01-07 Templates -- index card

2015.01.07 Templates – index card

For example, here’s the template I’ve been using for sketched books. Note: If you use Yasnippet for Org Mode properties, you may want to set yas-indent-line to fixed or the fields will get confused.

Gist: sbook

# key: sbook
# name: Sketched Book
# --

**** TOSKETCH ${1:short title}
      :TITLE: ${2:long title}
      :SHORT_TITLE: $1
      :AUTHOR: ${3:authors}
      :YEAR: ${4:year}
      :BUY_LINK: ${5:Amazon link}
      :BASENAME: ${6:`(org-read-date nil nil ".")`} Sketched Book - ${2:$(sacha/convert-sketch-title-to-filename yas-text)} - ${3:$(sacha/convert-sketch-title-to-filename yas-text)}
      :ISBN: ${7:ISBN}


***** TODO Sketchnote $1
:Effort: 2:00

[[elisp:sacha/prepare-sketchnote-file][Prepare the file]]

***** TODO Write personal reflection for $1
:Effort: 1:00

[[][View in calendar]]

****** Sketched Book - $2 - $3

$3's /$2/ ($4) ...

I’ve sketched the key points of the book below to make it easier to remember and share. Click on the image for a larger version that you can print if you want.

Haven't read the book yet? You can [[$5][buy it from Amazon]] (affiliate link) or get it from your favourite book sources.

Like this sketch? Check out [[][]] for more. Feel free to share – it’s under the Creative Commons Attribution License, like the rest of my blog.

***** TODO Post $1 to blog
:Effort: 1:00
:QUANTIFIED: Packaging

***** TODO Update sketched books collection
:Effort: 1:00
:QUANTIFIED: Packaging

1. [[elisp:sacha/index-sketched-book][Index sketched book]]
   - [[file:~/Dropbox/Packaging/sketched-books/][Edit index]]
   - [[file:~/Dropbox/Packaging/sketched-books/][Edit ebook]]
2. [[elisp:sacha/package-sketched-book][Compile]]
3. Update [[]]

***** TODO Tweet sneak peek of $1 with attached picture

[[elisp:(progn (kill-new (format "Sneak peek: Sketched Book: %s - %s %s" (org-entry-get-with-inheritance "SHORT_TITLE") (org-entry-get-with-inheritance "AUTHOR") (org-entry-get-with-inheritance "BLOG_POST"))) (browse-url ""))][Copy text and launch Twitter]]

It’s a lot of code and I keep tweaking it as I come across rough corners, but it’s handy to have that all captured in a template that I can easily expand. =)

Text transformation

One of the advantages of tweaking text expansion inside Emacs instead of using a general-purpose text expansion program is that you can mix in some Emacs Lisp to transform the text along the way. I’m still thinking about how to make the most of this, as you can see from this half-filled note-card:

2015-01-07 Text transformation as part of expansion -- index card

2015.01.07 Text transformation as part of expansion – index card

For example, this snippet makes it easier to share source code on my blog while also linking to a Gist copy of the code, in case I revise it or people want to comment on the code snippet itself. It doesn’t use any of the built-in text expansion capabilities, but I think of it as a text expander and transformer because it replaces work I used to do manually. You’ll need the gist package for this one.

Gist: Sacha

(defun sacha/copy-code-as-org-block-and-gist (beg end)
  (interactive "r")
  (let ((filename (file-name-base))
        (mode (symbol-name major-mode))
         (condition-case nil (buffer-substring beg end)
           (mark-inactive (buffer-string))))
        (gist (condition-case nil (gist-region beg end)
                    (mark-inactive (gist-buffer)))))
     (format "\n[[%s][Gist: %s]]\n#+begin_src %s\n%s\n#+end_src\n"
             (oref (oref gist :data) :html-url) filename
             (replace-regexp-in-string "-mode$" "" mode)

Both Yasnippet and Skeleton allow you to use Lisp expressions in your template. If you don’t have all the data yet, you might consider writing another Lisp function that you can call later when you do. For example, in the sketched books code above, I have an Emacs Lisp link that composes a tweet with a link, puts it in the clipboard, and then opens up a web browser. (I do this instead of posting directly because I also want to attach an image to that tweet, and I haven’t figured out how to modify any of the Emacs Twitter clients to do that.)

So that’s what I’ve learned so far about automating text in Emacs. It’ll take me more than a week to get the hang of the abbreviations I’ve just set up, and I’ll probably need to add even more before adding and using abbreviations become true habits. But hey, maybe this will help you pay closer attention to repetitive text and editing actions in Emacs so that you can automate them too, and we can swap notes on useful abbreviations. What kind of text do you expand?

For more information, see:

The post Developing Emacs micro-habits: Abbreviations and templates appeared first on sacha chua :: living an awesome life.

-1:-- Developing Emacs micro-habits: Abbreviations and templates (Post Sacha Chua)--L0--C0--January 21, 2015 01:00 PM

Flickr tag 'emacs': Emacs + Tern

zatsu posted a photo:

Emacs + Tern

-1:-- Emacs + Tern (Post zatsu ( 20, 2015 03:00 PM

Sebastian Wiesner: Why package.el?

Today, an Emacs user on Reddit asked how to organise their Emacs extensions, specifically whether to package.el or a “home-made” solution. This post answers that question. It’s essentially a copy of a Reddit comment of mine from about a year ago.

package.el goes beyond just fetching files, and

  • installs dependencies of a package,
  • adds packages to the load-path,
  • byte-compiles the package files,
  • generates and loads autoload definition (improves startup time, since package files are loaded on demand),
  • and registers manuals for the built-in Info viewer (lets your read manuals of packages right in Emacs).

The differences by example: Suppose you want to use Flycheck (shameless plug, sorry :) ), with all of the above features. You’d need to

  • manually install about six packages which are direct or indirect dependencies of Flycheck,
  • clone or update the Flycheck repository,
  • add the Flycheck directory to load-path,
  • run make compile,
  • run M-x update-directory-autoloads on the Flycheck directory,
  • load flycheck-autoloads.el in your init.el,
  • run make info (make sure that you have Texinfo, Python, Sphinx and a bunch of other packages installed),
  • and add the doc/ sub-directory of the Flycheck directory to Info-directory-list.

And most of these every time you update Flycheck.

With package.el, you’d just add the MELPA archive and run M-x package-install RET flycheck. See the difference? Does your manual workflow really work well?

Besides, as a package author, I consider package.el as the only official distribution channel for my extensions, and I refuse to provide support for other installation methods, so if you screw up on your manual installation, you’re on your own.

-1:-- Why package.el? (Post)--L0--C0--January 20, 2015 12:00 AM

Endless Parentheses: New in Emacs 25.1: Easily install multifile package from a directory

When developing a package, package-install-from-buffer is a very useful command. It installs the current buffer as an Elpa package, so you can test installation, byte-compilation, autoloading, and activation, all in one fell swoop. If your package has multiple files, however, it gets a little more complicated.

Earlier this month, I asked on Emacs.SE whether there was a simple way to manually install a multifile package. As discussed in Phils' answer, you need to create a -pkg.el file, tar the package, and then invoke a command on the tar file. That's two steps too many for me, so a push to master was in order.

As of today, Emacs 25.1 has a new feature. From the NEWS file:

** package-install-from-buffer and package-install-file work on directories. This follows the same rules as installing from a .tar file, except the -pkg.el file is optional.

There are no new commands to remember. Just issue package-install-from-buffer from a dired buffer, or invoke package-install-file and give a directory. Whichever package is contained in that directory will be read and installed, be it single or multifile, no taring or -pkg.el file necessary.

Comment on this.

-1:-- New in Emacs 25.1: Easily install multifile package from a directory (Post)--L0--C0--January 20, 2015 12:00 AM

Kunigami: Fixing emacs install path

I’ve recently switched from macports to brew. Things that were previously installed using macports were not working properly. For example emacs,

$brew list emacs

Returned the following:

/usr/local/Cellar/emacs/24.4/libexec/emacs/ (5 files)
/usr/local/Cellar/emacs/24.4/share/emacs/ (3822 files)
/usr/local/Cellar/emacs/24.4/share/icons/ (7 files)
/usr/local/Cellar/emacs/24.4/share/info/ (62 files)
/usr/local/Cellar/emacs/24.4/share/man/ (5 files)
/usr/local/Cellar/emacs/24.4/var/games/ (2 files)

But emacs, linked to /usr/local/bin/emacs was not linked to /usr/local/Cellar/emacs/24.4/bin/emacs

The fix was running

$brew link emacs

But before that I had to fix permissions to /usr/local/share/emacs which was set by macports:

-1:-- Fixing emacs install path (Post kunigami)--L0--C0--January 19, 2015 05:17 PM

sachachua: Improving my evil plans for Emacs

Mwahahaha. My evil plans are yielding results, or at least that’s the impression I get because I’m learning so much from people who tell me that they found my blog helpful years ago. Even more recent experiments bear fruit: punchagan checked out Memacs because of my Emacs Chat with Karl Voit, and ended up writing a blog post about using the Emacs profiler.

2015-01-17 My Evil Plans for Emacs are yielding results -- index card #emacs #sharing

2015-01-17 My Evil Plans for Emacs are yielding results – index card #emacs #sharing

This makes me curious: What am I doing right, and how can I do it even better?

Looking at my Emacs posts, it seems I mostly write about figuring things out (and occasionally about cool things I’ve come across). People like the enthusiasm, and they sometimes pick up cool ideas too. The Emacs Hangouts and Emacs Chats are my way of working around my limitations; I don’t particularly like travel and I’m not up to organizing in-person meetups, but virtual meetups let me reach out to more people (and we can record the conversations more easily, too).

What are my goals?

  • I want to get better at using Emacs, because it’s useful and it tickles my brain
  • I want to help more people become intermediate and advanced users of Emacs, because then I get to learn from them (and also Emacs thrives as a community). I can do this by:
    • Showing people the benefits and possibilities of customization
    • Working out loud, showing my thought processes and the tools/libraries I use
    • Helping people develop a good mindset and handy skills
    • Sharing little tips and neat functions

How can I get even better at helping the Emacs community?

2014-04-26 Helping the Emacs community #emacs

2014-04-26 Helping the Emacs community #emacs

I really like the way (or emacs has daily Emacs snippets and Rubikitch describes Emacs packages in Japanese. I think I’ll slowly ramp up from once-a-weekish Emacs posts to maybe twice or three times a week. I have more posts already scheduled, but I just spread them out so that my non-geek readers don’t get overwhelmed.


Because I’m interested in things that tend to be idiosyncratic (workflows, customizations, etc.), I have a hard time making clear recommendations or putting tips into logical order. That’s probably why I do a lot more “thinking out loud”-type posts instead. I can experiment with identifying who might find a tip useful, extract the tips from my thinking-out-loud explorations, and gradually build up sets of related tips that way.

2015-01-16 Hmm – not guides but explorations – index card #sharing #packaging

I did actually manage to put together one guide (How to Read Lisp and Tweak Emacs) and half of another A Baby Steps Guide to Managing Your Tasks With Org. The sketches for How to Learn Emacs and Tips for Learning Org Mode are high-level guides, too.


I’ve been going back to the basics, working on developing even better Emacs microhabits. I’ve focused on two so far: abbreviating text and switching windows.I think there’s plenty of space to improve even in terms of taking advantage of what’s already out there (with minimal configuration along the lines of setting variables and keyboard shortcuts). And then there are even bigger opportunities to improve through customization and Emacs Lisp.

Helping people directly

I’ve mentioned coaching a few times. Bastien Guerry and a few other folks offer coaching as a service. Me, I’m not particularly familiar with the kinds of issues people run into or are curious about (ex: Mac OS X, programming mode setup). I’m mostly curious about workflow, and I’m happy to talk to people about that. It could be a good source of ideas for blog posts.

2015-01-08 Imagining coaching or guiding others -- index card

2015-01-08 Imagining coaching or guiding others – index card

When I ran my Google Helpouts experiments, I turned many of those tips into blog posts. I think that would be even more effective if people wrote up those tips themselves (it’ll reinforce their learning and it will bring them into the community), so I’ve been playing with the idea of strongly encouraging or even requiring write-ups.

2015-01-15 What if I required people to pay it forward -- #workingoutloud #sharing #teaching

2015-01-15 What if I required people to pay it forward – #workingoutloud #sharing #teaching

Unrealistic, but one can dream. Or one can focus on helping people who are already sharing their questions and ideas in blog posts or discussion forums, so that’s another approach. There’s no shortage of questions, that’s for sure.


I like Emacs Hangouts more than one-on-one coaching. Hangouts are public and recorded automatically, so people can learn from them even if no one has posted notes. It’s shaping up to be a wonderful peer-coaching sort of thing, which is good because I don’t have to be so worried about not being able to help at all. I wonder what this would be like with a bit of a mastermind group structure; maybe we each pick a microhabit or idea to work on for the month (or for two weeks), we help each other out, and then we report back at the next one. That way, there’s casual conversation and discovery, but there’s also purpose and motivation.

2015-01-08 Imagining Emacs hangouts - index card

2015-01-08 Imagining Emacs hangouts – index card

2015-01-16 Emacs community -- index card #emacs

2015-01-16 Emacs community – index card #emacs

Connecting with more parts of the Emacs community

Evil-mode users are a growing part of the Emacs community. Maybe I should try it out to get a better sense of what the experience is like for people who are coming into Emacs via evil-mode. Besides, composability might be an interesting mental tool to add to my toolkit.

2015-01-18 Thinking about evil-mode and Emacs -- index card #emacs

2015-01-18 Thinking about evil-mode and Emacs – index card #emacs

Wrapping up

Maybe I can get better at helping the Emacs community by:

  • Focusing on those micro-habits and sharing what I learn (good for helping intermediate users develop a better appreciation of Emacs)
  • Playing with more workflow improvements and sharing them
  • Writing about how to tinker with popular packages like Org
  • Reaching out through blog comments and Emacs Hangouts to help people learn (in a publicly recorded way)
  • Bringing out what people know through Emacs Hangouts and Emacs Chats (especially if people know cool things but haven’t gotten around to writing about them)

Helping me get better at helping the Emacs community (my selfish reason: so that I learn more from people) can also support your evil plans (your selfish reason: so that you can learn more from me and from other people). Any suggestions? Tell me what I’m doing right and should do more of / better at, or tell me about somewhat adjacent things that are easy to do – low-hanging fruit! =)

The post Improving my evil plans for Emacs appeared first on sacha chua :: living an awesome life.

-1:-- Improving my evil plans for Emacs (Post Sacha Chua)--L0--C0--January 19, 2015 02:45 PM

Flickr tag 'emacs': 2015-01-18 Thinking about evil-mode and Emacs -- index card #emacs

sachac posted a photo:

2015-01-18 Thinking about evil-mode and Emacs -- index card #emacs

-1:-- 2015-01-18 Thinking about evil-mode and Emacs -- index card #emacs (Post sachac ( 19, 2015 01:30 PM

Endless Parentheses: Be a 4clojure hero with Emacs

This year I made it my resolution to learn clojure. After reading through the unexpectedly engaging romance that is Clojure for the Brave and True, it was time to boldly venture through the dungeons of 4clojure. Sword in hand, I install 4clojure.el and start hacking, but I felt the interface could use some improvements.

For starters, it's annoying that you need two commands to check the answer and move to next question. Sacha has a nice suggestion on this matter, a single command which checks the answer and moves to the next question. Nonetheless, I needed more.

Having to manually erase the __ fields to type my answer is absurd. Not to mention some answers are cumbersome to type inline. With the following command, you type your code at the end of the buffer; a lone archer lining up a shot to slay the problems above.

(defun endless/4clojure-check-and-proceed ()
  "Check the answer and show the next question if it worked."
        ;; Find last sexp (the answer).
        (goto-char (point-max))
        (forward-sexp -1)
        ;; Check the answer.
        (cl-letf ((answer
                   (buffer-substring (point) (point-max)))
                  ;; Preserve buffer contents, in case you failed.
          (goto-char (point-min))
          (while (search-forward "__" nil t)
            (replace-match answer))
          (string-match "failed." (4clojure-check-answers))))

The second encounter is simple in comparison. Just sharpen the blade, polish the shield, and we're ready for battle.

(defadvice 4clojure/start-new-problem
    (after endless/4clojure/start-new-problem-advice () activate)
  ;; Prettify the 4clojure buffer.
  (goto-char (point-min))
  (forward-line 2)
  (forward-char 3)
  ;; Position point for the answer
  (goto-char (point-max))
  (insert "\n\n\n")
  (forward-char -1)
  ;; Define our key.
  (local-set-key (kbd "M-j") #'endless/4clojure-check-and-proceed))

These two snippets have me cleaving effortlessly through the initial questions and I'm eager for the final challenges.

Both of these websites were recommended to me by Michael Fogleman. Do you know any other good clojure resources?

Comment on this.

-1:-- Be a 4clojure hero with Emacs (Post)--L0--C0--January 19, 2015 12:00 AM

Emacs Redux: Clear Comint Buffers

comint provides Emacs infrastructure for building command interpreters. It’s backing a lot of popular shell/REPL modes - like eshell, inferior-lisp, inf-ruby, inf-clojure, etc.

comint provides a myriad of built-in commands, but somewhat surprisingly it doesn’t feature a command to clear the contents of a comint buffer. Let’s write one such command ourselves!

While there are several way to tackle it, I feel this is the simplest (and the one that makes the best use of comint’s existing functionality):

(defun comint-clear-buffer ()
  (let ((comint-buffer-maximum-size 0))

;; let's bind the new command to a keycombo
(define-key comint-mode-map "\C-c\M-o" #'comint-clear-buffer)

Simple and elegant, right? One day it might even end up being part of comint itself.

-1:-- Clear Comint Buffers (Post)--L0--C0--January 18, 2015 07:57 PM

Alex Ott: ECB & fresh Emacs/CEDET...

Update (18th January 2015): the ECB now has new home:

I already twitted about this, and also wrote to ECB & CEDET mailing lists, but I also want to reach Planet Emacs readers :-)
I made small changes in the ECB code that allow to use it together with fresh Emacs & CEDET versions. Modified code is available in my github. I tried this version together with CEDET from trunk, and also with CEDET from Emacs 24.1, and it worked for me.
If you're using ECB, please try this modified version, and leave feedback (either here, or by sending e-mail to me or to ECB mailing list). If you'll find bugs, feel free to file a bug using github's issue tracker.
-1:-- ECB & fresh Emacs/CEDET... (Post Alex Ott ( 18, 2015 05:57 PM

Grant Rettke: Emacs lets you add buttons to your document

Of course it does.

Nice lightweight example of the difference between a document’s definition on the storage media (file-system) and its presentation to the user. Not to lean too hard on this, but if you grok what is happening here then you will enjoy Emacs a lot more.

Via here.

-1:-- Emacs lets you add buttons to your document (Post Grant)--L0--C0--January 18, 2015 02:57 PM

Emacs Redux: Customizing the Fringes

On graphical displays, each Emacs window normally has narrow fringes (gutters/margins) on the left and right edges. The fringes are used to display symbols that provide information about the text in the window. You can type M-x fringe-mode to disable the fringes, or modify their width. This command affects fringes in all frames; to modify fringes on the selected frame only, use M-x set-fringe-style. You can make your changes to the fringes permanent by customizing the variable fringe-mode.

Out-of-the-box the most common use of the fringes is to indicate a continuation line. When one line of text is split into multiple screen lines, the left fringe shows a curving arrow for each screen line except the first, indicating that “this is not the real beginning”. The right fringe shows a curving arrow for each screen line except the last, indicating that “this is not the real end”. If the line’s direction is right-to-left, the meanings of the curving arrows in the fringes are swapped.

Third-party modes like flycheck and diff-hl also make use of the fringe to display valuable information there (e.g. lint and VC information).

By default both fringes have width 8 pixels, but we can easily adjust this:

;; make both fringes 4 pixels wide
(fringe-mode 4)

;; make the left fringe 4 pixels wide and the right disappear
(fringe-mode '(4 . 0))

;; restore the default sizes
(fringe-mode nil)

As mentioned before, you can also invoke this command interactively and determine the optimal fringe size for you, before making it permanent in your config. The options presented by the fring-mode command are defined in the fringe-styles list:

(defconst fringe-styles
  '(("default" . nil)
    ("no-fringes" . 0)
    ("right-only" . (0 . nil))
    ("left-only" . (nil . 0))
    ("half-width" . (4 . 4))
    ("minimal" . (1 . 1)))
  "Alist mapping fringe mode names to fringe widths.
Each list element has the form (NAME . WIDTH), where NAME is a
mnemonic fringe mode name and WIDTH is one of the following:
- nil, which means the default width (8 pixels).
- a cons cell (LEFT . RIGHT), where LEFT and RIGHT are
  respectively the left and right fringe widths in pixels, or
  nil (meaning the default width).
- a single integer, which specifies the pixel widths of both

Be careful when playing with the fringe size. Certain info doesn’t look very good when the fringe is too small (e.g. less than 4 pixels).

-1:-- Customizing the Fringes (Post)--L0--C0--January 18, 2015 07:41 AM

Michael Fogleman: 2014: A Year of Emacs

My Emacs "birthday" is January 21, 2014. That's right-- I just started using Emacs this year! While it's not quite my one-year birthday, I thought I'd take advantage of the annual review blogging tradition to do a retrospective on my first year in Emacs. Note: much of the following chronology takes place during an extended romp through Asia.

I installed Arch Linux in the Fall of 2013. When using Linux, you often need to edit configuration files. The friend who helped me set me up with Vim. I learned the basics--how to insert, save, and quit--and not much else.

Arch on a bench

In January, I decided it might be fun to give Emacs a try. Here is a picture of Marina Bay in Singapore, taken just before or while I did the Emacs tutorial:

Marina Bay in Singapore, just before or during my Emacs birth

As a life-long user of keyboard shortcuts, I appreciated Emacs' notation for key bindings. The tutorial begins with basic cursor controls; easy enough, but nothing exciting. I could see the line, sentence, and buffer equivalents being useful. But my jaw dropped when it taught me C-t, transpose-chars. I knew that mastering just that command would probably save me a lot of pain and typos, and that was probably the least of what Emacs could do.

While the Emacs tutorial probably isn't meant to take more than an hour or two on the first try, it took me probably twice as long. This was because I made Anki cards. Some people say that Emacs' learning curve is steep. For myself, I've found Emacs' learning curve to be gentle, but (pleasantly) endless. Then again, it was probably making Anki cards that made the learning curve less steep for me.

A variation of this card was probably one of my first Emacs cards:

Anki card: transpose-chars 1

Cloze deletion cards like this one are very convenient for this kind of thing. One reason is that it's easy to add new, related information later:

Anki cards transpose-chars 2

In February, the battery on my little Arch laptop died. I spent most of the month without a laptop, waiting for a new battery to arrive by mail. I borrowed my friend and travel partner's machine to review my Anki cards. Still, I did manage to have a little time to develop my Emacs-fu.

In Hanoi, the hotel room we stayed in had a (virus-ridden) Windows machine. What else could I do but install Emacs? At this time, my Emacs configuration was not that complex, so it wasn't worth adapting. As it turned out, that time with a bare Emacs proved especially helpful for mastering some of the key Emacs concepts that I hadn't quite made use of yet; in particular, I got the hang of using multiple buffers in one session. By the the end of February, my new battery had arrived, and I was back in the Emacs saddle.

In March, I converted my my Emacs configuration to an Org-literate format, and started tracking it with Git. This was really the first project that I used Git for, and it gave me an opportunity to learn Git.

The other highlight of March was starting to learn a little Elisp. I found Robert Chassell's "An Introduction to Programming in Emacs Lisp" especially helpful. Chassell's overview and Org-mode's fantastic documentation helped me to write my first significant piece of Elisp (some org-capture templates).

April started off with a bang when my Emacs configuration was featured in a major motion picture, Tron Legacy. But that wasn't nearly as exciting as making my first major mode, tid-mode.

In late June, Artur Malabarba launched his Emacs blog, Endless Parentheses. One of his early posts was about hungry-delete. I was excited about it, but found that it did not work with transient-mark-mode. Artur encouraged me to write a fix. I was very excited when Nathaniel Flath, the maintainer, agreed to merge my patches into hungry-delete. At about the same time, Artur posted an adapted version of my narrow-or-widen-dwim function to Endless Parentheses. Sacha Chua, Nathaniel Flath, and some other Emacs Lisp hackers also offered suggestions.

At the end of July, I started learning Clojure, and added an initial CIDER configuration. While reading the Clojure Cookbook, I decided to hack out a function that turned the pages. Ryan Neufeld, one of the co-authors, merged my pull request, and a while later, I saw my function mentioned on Planet Clojure.

In October, I purchased a Mac for a Clojure contracting job. (Knowing Emacs helped me get the job!) Adding the :ensure keyword to my use-package declarations made the Emacs configuration portion of my OS X set-up process near-instant and pain-free. It was a really cool feeling to be using the same Emacs configuration on two different machines. By the end of the month, both were running on the newly-released Emacs 24.4.

Once Emacs 24.4 was out, Artur posted an Emacs 25 wishlist to Endless Parentheses. I responded with this tweet:

This tweet indirectly led to the happy occasion of the Emacs Hangouts.

That just about brings us to this post. In retrospect, I can't believe it's been less than a year, or that I've learned so much. Thanks to everyone who has helped me so far on the endless path of mastering Emacs, especially Ben, Eric, Sacha Chua, Artur Malabarba, and Bozhidar Batsov.

Joseph Campbell was a Lisp guru

I want to close this post out with Sacha's tweet about 2015:

Like Sacha, I want to learn how to write and run tests in Emacs. I want to learn more about org-mode's features and possible workflows. More broadly, I'd like to make more posts about Emacs, and find other ways to contribute to the Emacs community. I'd like to learn more about Emacs core development. In terms of contrib, I'd like to help accelerate the release of Magit's "next" branch. Above all, I'm sure I'll keep tweaking my configuration.

-1:-- 2014: A Year of Emacs (Post Michael Fogleman)--L0--C0--January 16, 2015 09:17 PM

Michael Fogleman: Emacs can keep in touch

I've wanted to show a specific Emacs workflow that I've established at the Emacs Hangouts that I've attended, but thought it might require too much explanation for an Emacs Hangout. Hence, this post. You might be interested in this workflow if you regularly edit a specific text file in a particular way, run an external program with the same parameters. You might also get some ideas if you're an Emacs-wielding programmer, and wish Emacs had some particular functionality, but would prefer to use Bash or another language to give it that functionality.

Some time ago, my friend Ben started working on a side project called "Keep In Touch." The premise: you have friends, family, and acquaintances that you'd like to stay in touch with. You maintain a list of those people, how often you'd like to contact them, and when you last contacted them. Keep In Touch can then figure out who you are out of touch with. For example, if you want to talk to someone every 30 days, but it's been 31 days, then you are out of touch with them, and the program tells you so. Simple!

Since I started using the program, I've fallen in love with using it. It has helped me to stay in touch with more people, more often. Moreover, I re-implemented Keep in Touch in Clojure as an exercise. And while Keep in Touch provides a serviceable CLI, I've worked out a simple Emacs interface for maintaining the database and viewing the program's output.

It all starts with telling Emacs where it can find the database:

(setq keepintouch-datafile "~/Dropbox/")

Next, I needed a way to tell Emacs that I had contacted someone. The result is an interactive function that asks you who you contacted. It ordinarily assumes that you contacted the person today, but with a prefix argument, it asks you for an alternate date. Then it opens the file and makes the appropriate changes.

(defun keptintouch (arg)
  "Request a contact in a file, and update their last
  contacted date (either today, or, if a prefix is supplied, a user-supplied date.)"
  (interactive "P")
  (let ((contact (read-string "Who did you contact? "))
        (date (if (equal arg nil)
                  (format-time-string "%Y/%m/%d")
                (read-string "When did you contact them? (year/month/date): "))))
      (find-file keepintouch-datafile)
      (goto-char (point-min))
      (search-forward contact)
      (forward-line -1)
      (insert date)
      (switch-to-buffer (other-buffer))
      (kill-buffer (other-buffer)))
    (message "%s was contacted." contact)))

"keptintouch" uses read-string to ask you who contacted, and, if need be, when you contacted them. It uses format-time-string to format today's date in the appropriate format.

The body of the function works almost like a keyboard macro. Often, you can start writing an Elisp function by hitting "C-h k" (describe-key) and finding out what functions are called when you execute the steps as keystrokes. Another way to do this quickly might be to make the keyboard macro, run edit-last-kbd-macro, and use the function annotations to read their documentation or make pseudo-code.

One reason that this is a function instead of a keyboard macro is that it uses some buffer management functions. (All interactive functions are of course accessible to keyboard macros through keyboard strokes, which can really save you some time in one-off situations!) It opens my Keep In Touch database in a new buffer, finds the contact, edits their last contacted date, saves, closes, and switches the buffers. If all went well, it reports success with message. If for some reason the contact is non-existent, search-forward will throw an error. (If that happens, or I want to view or edit the datafile manually, I find it with ido-recentf-open.)

All of this is wrapped in save-excursion, which is kind of like the shell commands popd and pushd except for buffers. In other words, it does something, and then returns the user to what they were doing before they executed the function.

Now that I had a way to maintain the database, I needed a way to run Keep in Touch and view its output, a sorted backlog of people that you are out of touch with.

The Clojure version of Keep in Touch is designed to be exported to a .jar file. Running the resulting program from the command line looks like this:

# note the special location of the .jar
cd target/uberjar
java -jar keepintouch-0.1.0-SNAPSHOT-standalone.jar ~/Dropbox/ schedule backlog

I decided to look at shell-command's documentation to find a way to run this command and put the results into an output buffer. As it turns out, shell-command is that function. As expected, it takes an argument for the desired shell-command. But it also allows for two optional arguments: the name of an output buffer, and the name of an error buffer.

(defun keptintouch-backlog ()
  "Create a buffer with Keep In Touch backlog."
  (let ((src "~/src/keepintouch/clj/keepintouch")
        (jar "-jar target/uberjar/keepintouch-0.1.0-SNAPSHOT-standalone.jar")
        (cur default-directory)) 
    (cd src)
     (concat "java " jar " " keepintouch-datafile " schedule backlog")
     "*Keep In Touch Backlog*")
    (cd cur)))

You'll see that the concat will expand to the shell command that runs the .jar, and that it is followed by an appropriate buffer name.

All of this Lisp makes its way to my finger with two key-binds (by way of use-package's bindkey.el):

(bind-keys ("C-c k" . keptintouch)
           ("C-c K" . keptintouch-backlog))

One variable, two functions, and two keybinds are all it took to make my life easier and get back to staying in touch with friends. You can eat your Emacs cake, and have defun, too.

-1:-- Emacs can keep in touch (Post Michael Fogleman)--L0--C0--January 16, 2015 09:17 PM

punchagan: org-drill for making it stick!

Those who read the last few posts here, would know that I have been experimenting with org-drill (a spaced repetition extension to Org mode). I have been using the system (almost) religiously for the past 2 months, and I do find that it has helped a great deal! (in some respects). I have also spent a considerable amount of time trying to reduce the friction to put new stuff into the system, and am constantly on the look out for further improvements.

Using this system has definitely helped with retention, and I find that I can recall quite a few things I have read a few weeks ago, that I would normally have been unable to. Though, I can recall a lot of information, I have been having a feeling of "fragmentation": the feeling of just retaining individual bits/fragments of information, while losing out on actually internalizing the knowledge; not seeing the big picture, etc.

Wozniak (the author of super-memo) warns against learning without understanding, and memorizing before actually learning stuff. I haven't consciously added stuff into the system that I didn't understand (when I added it), but, later it does feel like I have lost some connections or the understanding, and am only holding onto the fragments of information.

The problems as explained in (read: as interpreted by me from) Make it Stick appear to be:

  1. The understanding (if any) at the time of adding stuff into the spaced-repetition system is untested. It may just be familiarity masquerading as understanding.
  2. The lack of any spaced repetitions for the overall concept/understanding and actual repetitions only for individual bits doesn't help retention of the understanding (even if there was any, in the first place).

To work around this, I'm going to try adding questions that test understanding, to the system. The Super-memo team strongly recommends keeping the drill items small and easy to answer. This may be helpful in keeping each drill session short, but I would really like to add conceptual questions to the system, and see how it goes. I hacked org-drill to allow me to type out answers, before looking at the "correct" ones. This is an adaptation of a system that a fellow Hacker Schooler uses, and shared. Also, hopefully forcing myself to type out the answer will help me get around the problem of sometimes saying "yeah I know that", then looking at the answer only to reaffirm the feeling of familiarity, rather than actually testing myself. I'm still going to continue adding quick and short questions that test "bits of information", though. But, hopefully the additional conceptual questions are going to tie things together and help fill in the gaps. Lets see how this goes!

For those interested, my hacks to org-drill below. The code is really a hack, and welcome any suggestions on cleaning up the code.

(advice-add 'org-drill-presentation-prompt :around 'pc/org-drill-presentation-prompt)

(defun pc/org-drill-presentation-prompt (old-fun &rest fmt-and-args)
  "A presentation prompt that allows capturing answers."

  (let ((cb (current-buffer))
	(heading (nth 4 (org-heading-components)))
	(entry-id (org-entry-get (point) "ID"))
	(input ""))
    (switch-to-buffer-other-window "*org-capture-drill-answer*")
    (insert "# Hit C-c C-c once you are done answering!\n")
    (insert (format "Answer: %s" heading))
    (org-entry-put (point) "QUESTION_ID" entry-id)
    (goto-char (point-max))
    (insert "  ")
    (org-time-stamp-inactive '(16))
    (insert "\n\n  ")
    (while (not (and input (equal input "")))
	(execute-kbd-macro input))
      (setq input (read-key-sequence nil)))
    (switch-to-buffer-other-window cb)
    (apply old-fun fmt-and-args)))

(advice-add 'org-drill-reschedule :around 'pc/org-drill-reschedule)

(defun pc/org-drill-reschedule (old-fun)
  "Calls the original reschedule, but also archives the answer"
  (prog1 (funcall old-fun)
    (let ((cb (current-buffer)))
      (switch-to-buffer-other-window "*org-capture-drill-answer*")
      (pc/org-refile-to-datetree "drill.org_archive")
      (message (buffer-name))
      (switch-to-buffer-other-window cb)
      (kill-buffer "*org-capture-drill-answer*"))))

(require 'org-datetree)
(defun pc/org-refile-to-datetree (journal)
  "Refile an entry to journal file's date-tree"
  (interactive "fRefile to: ")
  (let* ((journal (expand-file-name journal org-directory))
	 (date-string (or (org-entry-get (point) "TIMESTAMP_IA")
			  (org-entry-get (point) "TIMESTAMP")))
	 (dct (decode-time (or (and date-string (org-time-string-to-time date-string))
	 (date (list (nth 4 dct) (nth 3 dct) (nth 5 dct))))
    (with-current-buffer (or (find-buffer-visiting journal)
			     (find-file-noselect journal))
	(org-datetree-file-entry-under (current-kill 0) date)
	(bookmark-set "org-refile-last-stored")))
    (message "Refiled to %s" journal)))
-1:-- org-drill for making it stick! (Post punchagan)--L0--C0--January 16, 2015 07:36 PM

Aaron Hawley: User liberation: New video from the FSF

from community blog

The last 45 seconds is pretty cool. There's a build of Gstreamer, interspersed with screenshots of Gnome, Pitivi, Blender and Inkscape.

The work is licensed under CC0 and the FSF is looking for other translations. Currently, only French and the original English are available.

-1:-- User liberation: New video from the FSF (Post)--L0--C0--January 15, 2015 03:10 PM

Ben Simon: Dude. Got another Dell. So far, Loving it.

It was time to retire my ASUS laptop, and as has become my tradition these last few years, I hit the local Best Buy to see what I could replace it with. I'm not much of a hardware guy, so I went in with basic requirements: i7 processor, at least 8 gig of RAM, touch screen and a big 'ol hard drive. I really wanted a touch pad with physical buttons. Oh yeah, I'd like a 15 inch screen or smaller. For all the traveling we do, it's still not enough to warrant an ultralight machine. Better to save a few bucks and not buy super skinny (which would spend nearly 100% of the time sitting on my desk).

All the usual players had laptops that fit my basic specs. I suppose if there was anything new to check out it was the plethora of 2 in 1 machines. Most of which are laptops that allow their screen to fold all the way back to create a crude tablet. While admittedly sexy, I don't lounge with my work laptop, so I can't really justify buying one of these bad boys. It's plain vanilla for me, as that's what I need on a day-to-day basis.

Another option was to buy a laptop with a Solid State Hard drive. But what the heck am I going to do with a 256 Gig drive? How do people function with that little disk space, when 1 Terabyte is basically standard?

In the end I picked up yet another Dell. This one is a Insprion 15 7547 (I think it's this one at BestBuy).

I think this is the first time in my life I've bought a new laptop and technology is essentially the same as the last one I bought. It's the same processor, hard drive, RAM and touch screen. Best Buy was offering a few laptops with with 12 Gig of RAM, which was awfully tempting. But in the end, I was won over by what appeared to be Dell's solid build quality.

And after a week of using this bad boy, I can say that Dell has delivered. The keyboard is between adequate and good. And while I'm unhappy that I couldn't get a touch pad with physical buttons (what the heck!), I've found that Dell's touch pad is working well enough. In many respects the laptop is as plain as could be, but for my purposes, that's exactly what I needed.

I continue to be amazed at how quickly I go from a blank system to functioning work device. Here's the process I went through to get up and running:

  1. Installed Chrome. Buh-by IE.
  2. Installed cygwin, and rather than messing around with package selection, I used all defaults and added subversion.
  3. Used subversion to check out a cygwin setup script I maintain. This cript installs all the packages I require
  4. Installed emacs. I've found this package to be an ideal one to install on Windows
  5. Installed Firefox
  6. Created my 5 Firefox profiles
  7. For each Firefox profile I customized the theme (this makes telling the profile apart much easier) and installed the Lazrus Form Recovery plugin. This makes auto-filling of any and all forms a breeze. It's a must have.
  8. On my Dev and Dev Jr. Firefox profiles I installed Firebug, Colorzilla, Web Developer and DNS Flusher.
  9. Installed Picasa
  10. Installed Gimp

And that was it. I was now able to develop, run my business and blog--my basic laptop activities. At some point I'll need to migrate files over from my ASUS machine, but I'm not in a huge hurry to do this.

This latest setup has really made me appreciate how much of my work is in version control. In fact, the only thing on my machine besides code seems to be photos. I'm thinking maybe I'll setup all my photo to sync via Google Drive and perhaps not bother with Carbonite? Yeah, probably not a good idea.

Anyway, the Dell Inpsiron 15 is a solid machine. It won't impress your hardware friends. But it just works.

-1:-- Dude. Got another Dell. So far, Loving it. (Post Ben Simon)--L0--C0--January 09, 2015 03:28 PM

Phillip Lord: Lenticular Text: Looking at code from different angles

Like many developers I often edit both code and documentation describing that code. There are many systems for doing this; these can be split into code-centric systems like Javadoc which allow commenting of code, or document-centric systems like Markdown which allow interspersing code in documentation. Both of these have the fundamental problem that by focusing on one task, they offer a poor environment for the other.

In this article, I introduce my solution which I call lenticular text. In essence, this provides two syntactic views over the same piece of text. One view is code-centric, one document-centric but neither has primacy over the other, and the author can edit either as they choose, even viewing both at the same time. I have now implemented a useful version of lenticular text for Emacs, but the idea is not specific to a particular editor and should work in general. Lenticular text provides a new approach to editing text and code simultaneously.

Quick Links

  • The lentic package which implements lenticular text
  • A screen cast showing the lenticular source of lentic.el
  • A screen cast showing the use ot lentic.el in a literate workflow

Lentic.el is available on MELPA(-stable) and Marmalade.

The need for Literate Programming

The idea of mixed documentation and code goes back a long way; probably the best known proponent has been Donald Knuth in the form of literate programming. The idea is that a single source document is written containing both the code and the documentation source; these two forms are then tangled to produce the real source code that is then compiled into a runnable application or readable documentation.

The key point from literate programming is the lack of primacy between either the documentation or the code; the two are both important, and can be viewed one besides the other. Tools like Javadoc are sometimes seen as examples of literate programming, but this is not really true. Javadoc is really nothing more than an docstring from Lisp (or perl or python), but using comments instead of strings. While Javadoc is a lovely tool (and one of the nicest parts of Java in my opinion) it is a code-centric view. It is possible to write long explanations in Javadoc, but people rarely do.

There are some good examples of projects using literate programming in the wild, including mathematical software Axiom or even a book on graphics. And there are a few languages which explicitly support it: TeX and LaTeX perhaps unsurprisingly do, and Haskell has two syntaxes one which explicitly marks comments (like most languages) and the other which explicity marks code.

These examples though are really the exception that proves the rule. In reality, literate programming has never really taken off. My belief is that one reason for this is the editing environments; it is this that I consider next.

Editing in Modes

When non-programmers hear about a text-editor they normally think of limited tools like Notepad; an application which does essentially nothing other than record what you type. For the programmer, though, a text-editor is a far cry from this. Whether the programmer prefers a small and sleek tool like Vim, the Swiss-Army knife that is Emacs, or a specialized IDE like Eclipse, these tools do a lot for their users.

The key feature of all modern editors is that they are syntax-aware; while they offer some general functions for just changing text, mostly they understand at least some part of the structure of that text. At a minimum, this allows syntax highlighting (I guess there a still a few programmers who claim that colours just confuse them, but I haven’t met one for years). In general, though, it also allows intelligent indentation, linting, error-checking, compiling, interaction with a REPL, debugging and so on.

Of course, this would result in massive complexity if all of these functions where available all of the time. So, to control this, most text editors are modal. Only the tools relevant to the current syntax are available at any time; so, tools for code are present when editing code, tools for documentation when editing documentation.

Now, this presents a problem for literate programming, because it is not clear which syntax we should support when these syntaxes are mixed. In general, most editors only deal with mixed syntax by ignoring one syntax, or at most treating it conservatively. So, for example, AucTeX (the Emacs mode for LaTeX) supports embedded code snippets: in this case, the code is not syntax highlighted (i.e the syntax is ignored) and indentation function preserves any existing indentation (i.e. AucTeX does not indent code correctly, but at least does not break existing indentation). We could expand our editor to support both syntaxes at once. And there are examples of this. For instance, AucTeX (the TeX editor) allows both the code and the documentation to be edited with its DocTeX support — this is slightly cheating though, as both the code and the documentation are in the same language. Or, alternatively, Emacs org-mode will syntax highlight code snippets, and can extract them from the document-centric view, to edit them and then drop them back again.

The problem here is that supporting both syntaxes at once is difficult to do, particulary in a text editor which must also deal with partly written syntax, and may not always follow a grammar.

Literate Workflows

As well as the editor, most of the tools of the programmer are syntax aware also. Something has to read the code, compile the documentation and display the results. For a literate document, there are two approaches to dealing with this. The first is the original approach, which is to use a tool which splits the combined source form into the source for the code and the documentation. This has the most flexibility but it causes problems: if your code fails to compile, the line numbers in any errors come out in the wrong place. And source-level debuggers will generally work on the generated source code, rather than the real source.

The second approach is to use a single source form that all the tools can interpret. This works with Haskell for instance: code is explicitly marked up, and the Haskell compiler ignores the rest as comments. This is fine for Haskell, of course, but not all languages do support this. In my case, I wanted a literate form of Clojure and, while I tried hard, it is just not possible to add in any sensible way [1].

A final approach is to embed documentation in comments; Javadoc takes this approach. Or for a freer form of documentation, there are tools like Marginalia. As a general approach it seems fine at first sight, although I had some specific issues with Marginalia (chiefly, that it is markdown specific and is relatively poor environment for writing documentation). But in use, it leads right back to the problem of a modal editing: Emacs’ Clojure mode does not support it so, for example, refilling a marked-up list ignores the markup and the list items get forced into a single paragraph.

Lenticular Text

My new approach is to use Lenticular text. This is named after lenticular printing, which produces images that change depending on the angle at which they are viewed. It combines approaches from all three of these literate workflows. We take a single piece of semantics and give it two different syntactic views. Consider the “Hello World” literate code snippet written in LaTeX and Clojure (missing the LaTeX pre-amble for simplicity).

This prints "hello world".
(println "hello world")

Now, if this were Haskell, we could stop, as code environment is one of those that the compiler recognises. But Clojure does not; we cannot load this file into Clojure validly. And as it is not real Clojure, any syntax aware editor is unlikely to do sensible things. We could instead use a code-centric view instead.

;; This prints "hello world".
;; \begin{code}
(println "hello world")
;; \end{code}

This is now valid clojure but now LaTeX breaks. Actually, with a little provocation, it can be made valid LaTeX as well [1], but my toolchain does not fully understand LaTeX (nothing does other than LaTeX, I suspect), so again we are left with the editor not doing sensible things.

These two syntaxes, though, are very similar and there is a defined relationship between the two of them (comment/uncomment every line that is not inside a code environment). It is clearly possible to transform one into the other with a simple syntactic transformation. We could do this with a batch processing tool, but this would fail its purpose because one form or the other would maintain its primacy; as an author, I need to be able to interact with both. So, the conclusion is simple; we need to build the transformation tool into the editor, and we need this to be bi-directional, so I can edit either form as I choose.

This would give a totally different experience. I could edit the code-centric form when editing code-blocks, and I could edit the document-centric form, when editing comments. When in code-blocks, I would use the code-centric form and the editor should work in a code-centric mode: auto-indentation, code evaluation, completion and so on. In the comment blocks, with a document-centric view, I should be able to reflow paragraphs, add sections, or cross-reference.

But does it work in practice? The proof of the pudding is in the programming.

Lenticular Text For Emacs.

I now have a complete implementation of Lenticular text for Emacs, available as the lentic package ( The implementation took some thinking about and was a little tricky but is not enormously complex. In total, the core of the library is about 1000 lines long, with another 1000 lines of auxilliary code for user interaction.

My first thought was to use a model-view-controller architecture, which is the classic mechanism for maintaining two or more views over the same data. Unfortunately, the core Emacs data structure for representing text (the buffer) is defined in the C core of Emacs and is not easy to replace. Indirect buffers, an Emacs feature which lentic can mimic, for instance are implemented directly in the core. Secondly, MVC does not really make sense here: with MVC, the views can only be as complex as the model, and I did not want the lentic to be (heavily) syntax aware, so that it can work with any syntax. So, we do not have much in the way of a data model beyond the a set of characters.

Lentic instead uses a change percolation model. Emacs provides hooks before and after change; lentic listens to these in one buffer and percolates to the other. My first implementation for lentic (then called linked-buffers) simply copied the entire contents of a buffer and then applies a transform (adding or removing comments for instance). This is easy to implement, but inefficient, so it scaled only to 3-400 lines of code before it became laggy. The current implementation is incremental and just percolates the parts which have changed. To add a new transformation requires implementing two functions — one which “clones” changes and one which “converts” a location in one buffer to the location in the other.

Re-implementing this for other editors would not be too hard. Many of the core algorithms could be shared — while they are not complex in the abstract, for incremental updates there are quite a few (syntax-dependent) edge cases. Similarly, I went through several iterations of the configuration options: specifying how a particular file should be transformed. This started off being declarative but ended up as it should do in a lisp: with a function.

I now have transformations between lisp (Clojure and Emacs) and latex, org-mode and asciidoc. These use much of the same logic, as they demark code blocks and comment blocks with a start of line comment. This is essentially the same syntax that Haskell’s literate programming mode provides. The most complex transformation that I have attempted is between org-mode and emacs-lisp; the complexity here comes because emacs-lisp comments have a syntax which somewhat overlaps with org-mode and I wanted them to work together rather than duplicate each other. For all of these implementations, my old netbook can cope with files 2-3000 lines long before any lag starts to become noticable. Lentic is fast enough for normal, every day usage.


The experience of implementing lentic has been an interesting one. In use, the system works pretty much as I hoped it would be. As an author I can switch freely between document and code-centric views and all of the commands work as I would expect. When I have a big screen, I can view both document and code-centric views at the same time, side-by-side, “switching” only my eyes. I can now evaluate and unit-test the code in my Tawny-OWL [2] manual.

By building the transform into the editor, I can get immediate feedback on both parts of my literate code. And, my lenticular text is saved to file in both forms. As a result of this, no other tools have to change. Clojure gets a genuine Clojure file. LaTeX gets a genuine LaTeX file. And for the author, the two forms are (nearly) equivalent. We only care which is the “real” file at two points: when starting the two lentic views, and when versioning as we only want to commit one form. The decision as to which form is “primary” becomes a minor issue. The lentic source code, for example, is stored as an Emacs-Lisp file, which can transform into an Org-mode file, so that it can work with MELPA (as well as for bootstrap reasons). The manual I am working on is versioned in the LaTeX form but transforms into Clojure so that people cloning the repository will get the document first; I use Emacs in batch to generate Clojure during unit testing.

There are some issues remaining. Implementation wise, undo does not behave quite as I want, since it is sensitive to switching views. And, from a usability point-of-view, I find that I sometimes try capabilities from the code-centric view in the document-centric or vice versa.

Despite these issues, in practice, the experience is pretty much what I hoped; I generally work in one form of the other, but often switch rapidly backward and forward between the two while checking. I find it to be a rich and natural form of interaction. I think others will also.


I doubt that tooling is the only difficulty with literate programming, but the lack of a rich editing environment is certainly one of them. Lenticular text addresses this problem. So far I have used lenticular text to document the source code of lentic.el itself, and to edit the source of a manual. For myself, I will now turn to what it was intended for in the first place: literate ontologies allowing me to produce a rich description of a domain both in a human and computational language.

The notion of lenticular text is more general though, and the implementation is not that hard. It can be used in any system where a mixed syntax is required. This is a common problem for programmers; lenticular text offers a usable solution.


  1. P. Lord, "Further Experiments with Literate Programming", An Exercise in Irrelevance, 2014.
  2. P. Lord, "Tawny-OWL 1.3", An Exercise in Irrelevance, 2014.
-1:-- Lenticular Text: Looking at code from different angles (Post Phillip Lord)--L0--C0--January 07, 2015 02:14 PM

emacspeak: 3D: A Spatial Auditory Icon Theme Generated Using CSound

Using CSound To Generate Auditory Icons

1 Auditory Icon Theme: 3d

CSound is a sophisticated music sound synthesis system with a strong community of developers. I've played off and on with CSound ever since the early 90's and have always been intrigued by the possibility of algorithmically creating new auditory icon themes for Emacspeak using CSound.

Over the holidays last December, I finally got around to creating my first complete CSound-generated auditory icon theme – it is now checked into Emacspeak SVN as theme 3d. This theme is best experienced with headphones — many of the generated icons use spatial audio to good effect.

-1:-- 3D: A Spatial Auditory Icon Theme Generated Using CSound (Post T. V. Raman ( 06, 2015 05:15 PM

Sebastian Wiesner: My Emacs Configuration with use-package

In the past I used to keep my Emacs configuration completely in a single init.el file. For a long time this worked quite well, but of late my configuration became increasingly messy: Package configuration was mixed with utility functions, key bindings, and even larger code for entirely new features. Needless to say that my init file was in dire need of a very thorough cleanup.

I had heard a lot of good things about John Wiegley’s use-package macro, and in the days after Christmas I decided to sit down and try to refactor my Emacs configuration with use-package. The result was very pleasant, and much better than I had dared to hope.

1 The basics

The idea of use-package is to wrap all initialisation and configuration of a package in a top-level form. A typical use in my configuration looks like this:

(use-package whitespace
  :bind (("C-c T w" . whitespace-mode))
  (dolist (hook '(prog-mode-hook text-mode-hook conf-mode-hook))
    (add-hook hook #'whitespace-mode))
  :config (setq whitespace-line-column nil)
  :diminish whitespace-mode)

This form binds Whitespace Mode to C-c T w globally, enables it automatically for certain modes, and configures it. :bind and :init are evaluated immediately, whereas :config is deferred until after the package is loaded, similar to with-eval-after-load1. :diminish is just a shortcut for the diminish utility which removes minor modes from the mode line.

Now compare this to the same code without use-package, as it would appear in my init file before:

(global-set-key (kbd "C-c T w") #'whitespace-mode)

(dolist (hook '(prog-mode-hook text-mode-hook conf-mode-hook))
  (add-hook hook #'whitespace-mode))

(with-eval-after-load 'whitespace
  (setq whitespace-line-column nil)
  (diminish 'whitespace-mode))

Clearly the use-package variant is more concise and organised, and much easier to understand. It keeps everything related to a package in a single top-level form, which puts all of the scattered package initialisation and configuration code together. This alone made my init file much easier to understand, but the real power of use-package does not end here—in fact, I have not show you any of the really cool stuff yet!

2 Automatic package installation

These days most of the cool Emacs Lisp isn’t built-in like whitespace-mode but comes from MELPA. I have almost 100 3rd party packages in my Emacs. I’d be a huge pain to track and install these manually whenever I remove the package directory or move to a new machine, but with use-package I don’t have to2. use-package can automatically install missing packages:

(use-package imenu-anywhere
  :ensure t
  :bind (("C-c i" . imenu-anywhere)))

This feature is so convenient that I mostly stopped to install new packages via M-x list-packages. Now I add a use-package form for any new package to my init file right away, with some basic initialisation and configuration—usually from the Github README of the package—and an :ensure keyword, and type C-M-x to evaluate the form to install and setup the package in one go. I still need to bootstrap use-package explicitly at the beginning of my init file, though. This is not that pretty, but the obvious chicken-egg probably can’t be avoided otherwise:

(require 'package)
(setq package-enable-at-startup nil)
(add-to-list 'package-archives '("melpa" . ""))


;; Bootstrap `use-package'
(unless (package-installed-p 'use-package)
  (package-install 'use-package))

3 “Local” packages

While I try to use packages as much as possible, and also release most of my custom code as packages to MELPA, I still have some code in my configuration that is too small or too specific to my own workflow and my personal preferences to be released independently.

use-package makes it easy to maintain this code. I can keep it in separate libraries, pretending that they are proper packages installed with the package manager, and use use-package as usual to load my custom code. For example, I have a lunaryorn-simple library which contains many small helper functions for editing. It sits in the lisp/ subdirectory of my Emacs directory and is never installed with the package manager, but use-package lets me configure as if it were:

(use-package lunaryorn-simple
  :load-path "lisp/"
  :bind (([remap kill-whole-line]        . lunaryorn-smart-kill-whole-line)
         ([remap move-beginning-of-line] . lunaryorn-back-to-indentation-or-beginning-of-line)
         ("C-c u d"                      . lunaryorn-insert-current-date)))

The only special thing is :load-path, which adds the containing directory to Emacs’ load-path so that it can find my personal library. But I don’t need to care for autoloads and lazy loading: use-package automatically adds autoloads for all commands bound to keys in :bind. My library is loaded lazily when I invoke any of these commands, just like a regular package installed via the package manager.

With this feature I can keep my init file (almost) free of any code. It only contains package configuration now. My custom code is neatly tucked away in separate libraries that look just like regular Emacs packages. This does not only make my configuration easier to understand, it has also fundamentally changed my package development workflow.

Most of my packages are born out of small customisation and personal functions that grow as I extend them, until they are large and stable enough to be released as separate packages. Previously, making a package out of these was painful: I had to manually extract all the required code form my init file and fix various compiler warnings and errors, naturally making many mistakes on the way.

Now I start with a separate library right away, which is a proper package on its own. All code goes through Flycheck to make sure that there are no errors or warnings. Once the package is suitable for an independent release, there’s no special work left: It’s all already there, and all that I still need to do is to move the file to a dedicated repository, add a README, and push it to MELPA. I think you can expect quite some new packages from me over the next time!

4 Idle initialisation

use-package also helps me to keep my Emacs startup fast with “idle initialisation”, which initialises packages after Emacs was started and has been idle for some time. I use this feature mainly for global modes that are slow to load and enable.

Company for instance is a powerful completion package, but it also large and takes time to load and enable. On the other hand, completion is not so important for me that I need it immediately, so I delay its initialisation:

(use-package company
  :ensure t
  :defer t
  :idle (global-company-mode))

With this configuration global-company-mode is delayed until Emacs has been idle. As a result, Emacs starts faster: Packages of less importance do not contribute to startup time anymore. They are initialised later, when Emacs doesn’t have to do anything else anyway.

5 Final words

use-package is really a great tool to manage and maintain your init file, which helps to keep even large configurations concise and clean and avoids the dreaded Emacs bankruptcy. Take a look at the Github Page and read its README, which shows even more cool features than this post.

I’d like to thank John Wiegley for this great package, and for all his other work on Emacs!

  1. Strictly speaking, :config is only deferred in some cases, i.e. with :defer t, or when using :bind, :commands or a similar keyword—the documentation has the details. But in almost all cases you want :config to be deferred, so for simplicity let’s assume that :config is always deferred.

  2. Actually, I never managed my packages manually. Before use-package I kept a list of packages at the beginning of my init file, together with some custom code to install all missing packages automatically. This did not work too well, though: Frequently I forgot to update the list when I installed a new package and ended up with load-time errors.

-1:-- My Emacs Configuration with use-package (Post)--L0--C0--January 06, 2015 12:00 AM

punchagan: How I learnt to use Emacs' profiler

I learnt to use Emacs' profiler yesterday, after many hours of yak-shaving, trying to get Memacs working. Memacs is a memory extension system for Emacs written by Karl Voit, that I have been meaning to try out for a long time now. Seeing lots of review posts at the turn of the year and watching Karl's recent Emacs Chat with Sacha Chua pushed me to try and finally set it up.

I started writing a module to create a Memacs file – an org archive file – from my browser history. It was pretty easy to write, and I had it spitting out a huge file with 22k entries after about a couple of hours of work. Then I excitedly pulled up my agenda, and turned on the option to view archived entries, only to be super-disappointed. It turned out to be extremely slow! Actually, the agenda never came up with the 22k entries file that I had. At least not in 5 or so minutes, before I got impatient. The performance was unacceptable even when I reduced it to 5k entries.

I was pretty sure it wasn't that slow for Karl in his demo and tweeted to him, asking for a workaround. Meanwhile, I looked at his dot-emacs, but wasn't able to dig out what was needed to speed up things. He confirmed that his performance was way better than what I was getting.

First, I ruled out the possibility of it being because of the SSD, since clearly my CPU usage was peaking, and the task was CPU bound and not I/O. Next, I tried using the same file on a different machine (with a different version of Emacs and org-mode), and it worked blazingly fast. So, it was either the version of Emacs or org-mode that I was using.

I should have stopped, thought clearly, and started experimenting with org version, but hindsight is 20-20. I tried Ubuntu's pre-built Emacs and agendas were fast! I suspected my Emacs build, since I recently started building Emacs from git. I built two or three other versions of Emacs, and wasted a lot of time, before realizing that I wasn't using the org-mode source bundled inside Emacs for the tests, and there were two "independent" variables.

Finally, I began bisecting org-mode's source and found that all hell broke loose with an inconspicuous change around release 8.2.6. It turns out that org-overview was broken before this, and collapsing all the trees in a newly opened org-buffer (default option) wasn't working. Once this bug was fixed, opening huge org files would slow down by a great deal, in turn causing agenda generation to be unbearably slow.

All I had to do was add a #+STARTUP: showeverything to the top of the file. This speeded up things by about 50 times! It turns out, I later found out, that all of this is documented on Worg. I did try a few search engine queries, but sadly none of them brought this up. Adding the following to my config, speeded up agenda generation by about 150-200 times!

(setq org-agenda-inhibit-startup t) ;; ~50x speedup
(setq org-agenda-use-tag-inheritance nil) ;; 3-4x speedup

In the course of all this debugging, I learnt how to use Emacs' profiler. The profile reports along with git bisect, eventually helped me figure out what the problem was.

To profile the CPU usage, all you have to do is add a call like

(profiler-start 'cpu)  ;; or M-x profiler-start

at the place where you wish to start it. Emacs will then start collecting information about where time is being spent, by sampling every sampling-interval seconds (default 106 nanoseconds = 1 milli second).

You can view the information being collected, at any point of time using

(profiler-report) ;; or M-x profiler-report

The report is a nice, interactive tree with the percentage of time spent in each call. You can stop profiling by calling (profiler-stop). If you have more than one report, you can compare them by hitting = in one of the report buffers. I'm definitely going to use this for other things! (like speeding up my startup?)

Now that I have Memacs working with reasonably fast agenda views, I'm looking forward to collecting as much personal information as I can! Thanks Karl for writing Memacs. I am going to be a pretty heavy user, I think! There seem to be a few rough edges, though, and I hope to help smoothen them out a little bit, over the next few weeks.

-1:-- How I learnt to use Emacs' profiler (Post punchagan)--L0--C0--January 02, 2015 08:31 PM

Ben Simon: More Hand Held Hacking: Forth on Android

I was inspired to try to get a version of Forth running on my cell phone. I've had quite a bit of success developing small Scheme programs on my Galaxy S5 and was curious if I could manage the same thing with Forth.

I installed gforth from Google Play hoping that it would be a solid implementation. Unfortunately, I was met with a non-functional mess:

Besides spitting out the debugging statement log: setComposingRegion, the app didn't do much more. That is, until I switched keyboards. I changed from Swift Key to the keyboard that comes with Terminal IDE. Ahhhh, much better:

Now we were talking!

Poking around, I learned that there's quite a few Forth files to be had in: /sdcard/gforth/site-forth. Between browsing those files, and looking at the gforth manual, I came up with the command:

  require gl-sample.fs

Running that pops up this graphic:

I don't know what to make of this, other than the fact that gforth isn't just some half-baked toy. This is a real forth implementation, with some impressive features (assuming of course that I can unlock them).

All of this was optimistic, but I was still not sure I could turn this into a mobile friendly dev environment. Taking a cue from my Scheme workflow I setup the following:

First, I created a keyboard shortcut that allows me to type Alt-o and be dropped into Forth. With the existing keyboard shortcuts in place, I can type Alt-M to switch to an editor Alt-o to switch me back to gforth.

Next, I created a file named .gforthrc in:


and put the following contents in it:

." BAS init " cr
: lex ( - )
 s" /sdcard/Documents/ex1.fs" included ;

That code doesn't do a whole lot other than announce that the file was executed setup the word lex for me to use. .gforthrc is a magic file, in that it gets loaded anytime gforth is started up.

The lex word, like the scheme equivalent (lex), loads a specific exercise file. In this case, /sdcard/Documents/ex1.fs. This allows me to open this file up in the editor, make changes, switch to gforth and type lex to reload in this file.

I've got a nice edit-eval loop, and when I'm done I can copy ex1.fs into a local git repository for archiving.

I've got to say, the setup truly works!

For now, I've been refreshing my Forth basics by going through the gforth tutorials. Though, I'm eager to tackle the Christmas Programming Praxis challenge, which involves solving 6 'ancient' algorithms. Should be the perfect way to freshen up my Forth skills.

At a minimum I can say this: gforth on Android rocks.

-1:-- More Hand Held Hacking: Forth on Android (Post Ben Simon)--L0--C0--December 30, 2014 01:28 PM