Why I Buy Moleskine Journals

I keep a diary and also a programming journal. Because I want to keep all of my ideas down for future reference, I prefer to use nice journals for them (no spiral notebooks or ones with perforated pages). For these purposes, I turn to the Moleskine brand of journals — more specifically, their Folio line of A4-sized notebooks.

Yes, the Moleskine line of journals are quite overpriced. Yes, they are not made in Europe as the name implies (they are made in China). However, Moleskine is quite possibly the only company in the world that makes journals that fit the following criteria:

  • Sewn binding (pages can lie flat for sane writing)
  • A4 or larger size
  • Blank/lined/graph pages
  • Hardcover
  • Regular paper (not sketch paper)

I think some of Clairefontaine’s journals come close, but all of their A4-sized journals are lined, I believe. And plus, as great as their paper quality is (it really is fantastic to write on), it is way too bright for my taste.

By the way, if you are a programmer I strongly recommend that you keep your notes in a physical notebook. If you are learning a new programming language or starting to sketch the design goals of a new programming project, keeping a notebook for it is quite possibly one of the best decisions you will make.

Oh, by the way, you should purchase a good pen to go along with your journal(s). Don’t write with horrible, cheap pens that are difficult to write with.

Advertisements

Easy Solutions to Hard Problems?

I’ve been trudging along knee-deep in tree manipulation algorithms recently, all in Haskell. I admit, calling them “algorithms” makes me sound much smarter than I really am… what I actually worked on was converting one type of tree into another type of tree (functionA) and then back again (functionB), such that I would get back the original tree — all in a purely functional, stateless, recursive way. My brain hurt a lot. I hit roadblock after roadblock; still, I managed to go through each hurdle by sheer effort (I never studied computer science in school).

See, I have a habit of solving typical Haskell coding problems in a very iterative fashion. Here are the steps I usually follow:

  1. Research the problem domain (Wikipedia, StackOverflow, etc.)
  2. Take lots of loose notes on paper (if drawing is required), or on the computer (using emacs’ Org-mode).
  3. Write temporary prototype functions to get the job done.
  4. Test said function with GHCi.
  5. Repeat Steps 1 through 4 until I am satisfied with the implementation.

The steps usually work after one or two iterations. But for hard problems, I would end up going through many more (failed) iterations. Over and over again, hundreds of lines of Haskell would get written, tested, then ultimately abandoned because their flawed design would dawn on me halfway through Step 3. Then I would get burned out, and spend the rest of the day away from the computer screen, doing something completely different. But on the following day, I would cook up a solution from scratch in an hour.

It’s such a strange feeling. You try really hard for hours, days, weeks even, failing again and again. Then, after a brief break, you just figure it out, with less mental effort than all the effort you put in previously.

What can explain this phenomenon? The biggest factor is obviously the learning process itself — that is, it takes lots of failures to familiarize yourself intimately with the problem at hand. But the way in which the solution comes to me only after a deliberate pause, a complete separation from the problem domain, fascinates me. I call it the “Pause Effect” (PE), because I’m too lazy to dig up the right psychological term for this that probably exists already.

So, here’s my new guideline for solving really hard problems:

  1. Try to solve problem in a “brute-force” manner. Don’t stop until you burn out. I call this the “Feynman Step”, after a quote from the televised “Take the World from Another Point of View” (1973) interview, where, toward the end, he describes a good conversation partner — someone who has gone as far as he could go in his field of study. Every time I’m in this step, I think of how animated Feynman gets in his interview, and it fires me up again.
  2. Rest one or two days, then come back to it. This is the “PE Step”.

The best part is when you ultimately find the solution — it feels incredible. You get this almost intoxicating feeling of empowerment in yourself and in your own abilities.

Xorg: Using the US International (altgr-intl variant) Keyboard Layout

TL;DR: If you want to sanely type French, German, Spanish, or other European languages on a standard US keyboard (101 or 104 keys), your only real option is the us layout with the (relatively new) altgr-intl variant.

I like to type in French and German sometimes because I study these languages for fun. For some time, I had used the fr and de X keyboard layouts to input special characters from these languages. However, it wasn’t until recently that I realized how most European layouts, such as fr and de, require that you have a 105-key keyboard. A 105-key keyboard looks exactly like the standard, full-sized IBM-style 104-key keyboard (i.e., IBM Model “M” 101-key keyboard plus 2 Windows keys and 1 “Menu entry” key on the bottom row), except that it has 1 more extra key on the row where the Shift keys are (and also has a “tall” Enter key with some of the existing keys on the right side rearranged a bit).

I personally use a 104-key keyboard (a Unicomp Space Saver 104, because that’s how I roll). Now, when I switched to the fr layout the other day, I wanted to type the word âme. Unfortunately, the circumflex dead key was not where it was supposed to be. This was because I only had 104 keys instead of 105, and during the process of switching forcibly to the fr layout, there was a malfunction in the conversion (rightfully so).

Now, the choice was to either buy a 105-key keyboard or just find an alternative 104-key layout that had dead keys. I didn’t want to buy a new 105-key keyboard because (1) the extra 1 key results in a squished, “square” looking left-Shift key and (2) the tall Enter key would make it more difficult for me to keep my fingers happy on the home row, since I’d have to stretch my pinky quite a bit to reach it, and (3) I just didn’t feel like spending another ~$100 for a keyboard (my Unicomp is still in excellent condition!).

So, I had to find a new keyboard layout that could process accented/non-English Latin characters better. The Canadian Multilingual Standard keyboard layout (http://en.wikipedia.org/wiki/Keyboard_layout#Canadian_Multilingual_Standard) looked very, very cool, but it was only for a 105-key keyboard. I then discovered a layout called the US International Standard keyboard layout, which enables you to type all the cool accented letters from French or German (and other European languages) while still retaining a QWERTY, 101/104 key design. This sounded great, until I realized that the tilde (~), backtick (`), single quote (‘) and other keys were dead keys. I.e., to type ‘~’ in this layout, you have to type ‘~’ followed by a space. This is horrible for programmers in Linux because the ~ key comes up everywhere (it’s a shell shortcut for the $HOME directory). To type a single quote character, you have to type (‘) followed by a space! Ugh. I’m sorry, but whoever designed this layout was obviously a European non-programmer who wanted to type English easier.

But then, all hope was not lost. When browsing all of the choices for the us keyboard layout variant under X (/usr/share/X11/xkb/rules/base.lst), I found a curious variant called altgr-intl. A quick google search turned up this page, an email from the creator of this layout to the X developers: http://lists.x.org/archives/xorg/2007-July/026534.html. Here was a person whose desired usage fit perfectly with my own needs! Here’s a quote:

I regularly write four languages (Dutch, English, French and German)
on a US keyboard (Model M – © IBM 1984).

I dislike the International keyboard layout. Why do I have to press
two keys for a single quote (‘ followed the spacebar) just because the
‘ key is a dead-key that enables me to type an eacute (é)?

I decided to ‘hide’ the dead-keys behind AltGr (the right Alt key).
AltGr+’ followed by e gives me eacute (é). It also gives me
m² (AltGr+2).

Excellent! Apparently, this layout was so useful that it became included eventually into the upstream X codebase, as the altgr-intl variant for the standard us (QWERTY) keyboard layout. The most compelling feature of this layout is that all of the non-US keys are all hidden behind a single key: the right Alt key. If you don’t use the right Alt key, this layout behaves exactly the same as the regular plain us layout. How cool is that?! And what’s more, this layout makes it compatible with the standard 101-key or 104-key IBM-styled keyboards!

This variant deserves much more attention. Unfortunately, there seems to be little or no information about it other than the above-quoted email message. Also, I’ve noticed that it is capable of generating Norse characters as well, like þ and ø. There does not seem to be a simple keyboard layout picture on the internet to show all the keys. Anyway, I’ve been using it recently and it really does work great. There is no need for me to switch between the us, fr, and de layouts to get what I want. I just use this layout and that’s it. Take that, Canadian Multilingual Standard!

Here’s how to set it up: use either the setxkbmap program like this:

setxkbmap -rules evdev -model evdev -layout us -variant altgr-intl

in a script called by ~/.xinitrc, or use it directly in your keyboard xorg settings:

Section "InputClass"
    Identifier "Keyboard Defaults"
    MatchIsKeyboard "yes"
    Option  "XkbLayout" "us"
    Option  "XkbVariant" "altgr-intl"
EndSection

I personally prefer the script method because you can tweak it easily and reload it without restarting X. For me, I had to use the -rules evdev -model evdev options because -model pc104 would mess things up (probably due to an interaction with xmodmap and such in my ~/.xinitrc). Whatever you do, make sure everything works by testing out the AltGr (right Alt) key. For example, AltGr+a should result in ‘á’.

A couple caveats: Some keys like â and è (which are AltGr+6+a and AltGr+`+e (i.e., uses dead keys)) do not show up at all on urxvt. I’m guessing that the dead keys are broken for urxvt (or maybe it’s a bug with this layout; who knows). Luckily, I can just use a non-console app (like GVIM) to do my Euro-language typing, so it’s OK (although, eventually, I’ll run into this bug again when I start typing French emails from within mutt inside urxvt 20 years later… but by then it will be fixed, I’m sure.) Also, the nifty xkbprint utility can generate nice pictures of keyboard layouts (just do a google image search on it), but it’s currently missing (https://bugs.archlinux.org/task/17541) from Arch Linux’s xorg-xkb-utils package. So, if you’re on Arch, you’ll have to experiment a bit to figure out the various AltGr+, and AltGr+Shift+ key combinations.

See also: Xorg: Switching Keyboard Layouts Consistenly and Reliably from Userspace

UPDATES:

  • October 30, 2011: I just found out that the dead keys bug in urxvt is actually a bug in ibus/SCIM (I use ibus, which relies on SCIM, to enter Japanese/Korean characters when I need to). I tried out uim, which is a bit more complicated (much less user friendly, although there are no technical defects, from what I can tell), and with uim, the dead keys work properly in urxvt. The actual bug report for ibus is here.
    So, use uim if you want to use the altgr-intl layout flawlessly, while still retaining CJK input functionality. Of course, if you never needed CJK input methods in the first place, this paragraph shouldn’t concern you at all.
  • December 7, 2011: Fix typo.
  • January 24, 2012: Fix grammar.

Things I Like About Git

Ever since around 2009-2010, developers have been engaging in an increasingly vocal debate about version control systems. I attribute this to the hugely popular rise of the distributed version control systems (DVCSs), namely Git and Mercurial. From my understanding, DVCSs in general are more powerful than nondistributed VCSs, because DVCSs can act just like nondistributed VCSs, but not vice versa. So, ultimately, all DVCSs give you extra flexibility, if you want it.

For various reasons, there is still an ongoing debate as to why one should use, for example, Git over Subversion (SVN). I will not address why there are still adamant SVN (or, gasp, CVS) users in the face of the rising tsunami tidal wave of DVCS adherence. Instead, I will talk about things I like about Git, because I’ve been using it almost daily for nearly three years now. My intention is not to add more flames to the ongoing debate, but to give the curious, version control virgins out there (these people do exist!) a brief rundown of why I like using Git. Hopefully, this post will help them ask the right questions before choosing a VCS to roll out in their own machines.

1. Git detects corrupt data.

Git uses an internal data structure to keep track of the repo. These objects, which are highly optimized data structures called blobs, are hashed with the SHA-1 algorithm. If suddenly a single byte gets corrupt (e.g., mechanical disk failure), Git will know immediately. And, in turn, you will know immediately.

Check out this quote from Linus Torvalds’ Git talk back in 2007:

“If you have disc corruption, if you have RAM corruption, if you have any kind of problems at all, git will notice them. It’s not a question of if. It’s a guarantee. You can have people who try to be malicious. They won’t succeed. You need to know exactly 20 bytes, you need to know 160-bit SHA-1 name of the top of your tree, and if you know that, you can trust your tree, all the way down, the whole history. You can have 10 years of history, you can have 100,000 files, you can have millions of revisions, and you can trust every single piece of it. Because git is so reliable and all the basic data structures are really really simple. And we check checksums. And we don’t check some UDP packet checksums that is a 16-bit sum of all the bytes. We check checksums that is considered cryptographically secure.

[I]t’s really about the ability to trust your data. I guarantee you, if you put your data in git, you can trust the fact that five years later, after it is converted from your harddisc to DVD to whatever new technology and you copied it along, five years later you can verify the data you get back out is the exact same data you put in. And that is something you really should look for in a source code management system.”

(BTW, Torvalds, opinionated as he is, has a very high signal-to-noise ratio and I highly recommend all of his talks.)

2. It’s distributed.

Because it is based on a distributed model of development, merging is easy. In fact, it is automatic, if there are no conflicting changes between the two commits to be merged. In practice, merge conflicts only occur as a result of poor planning. Sloppy developers, beware!

Another benefit of its distributed model is that it naturally lends itself to the task of backing up content across multiple machines.

3. It’s fast.

I can ask Git if any tracked files in a repo have been edited/changed with just one command: git diff. And it needs but a split second, even if my $PWD is not the repo’s root directory or if there are hundreds and thousands of tracked files littered across everywhere (because Git doesn’t think in terms of files, remember?)

4. It gives me surgical precision before and after committing changes.

Several things help me keep my commits small, and sane. The biggest factor is the index concept. Apparently, Git is the only VCS that gives you this tool! After editing your files, you go back and select only those chunks you want to be in the commit with git add -p. This way, you are free to change whatever you think is necessary in your files, without any nagging idea in the back of your mind going, “Hey, is this change exactly what you need/intended for your next commit?”

The other big factor is the rebase command. With rebase, I can do pretty much anything I want with my existing commits. I can reorder them. I can change their commit messages (known as amending). I can change the commits themselves (i.e., change the diffs). I can change 4 tiny commits into a single commit (known as squashing). I can even delete a commit (as long as the later commits do not rely on it). Essentially, you can rewrite your commits in any you like. This way, you can sanitize your commits in a logical way, regardless of work history.

Other Thoughts

I could go on, but the remaining points don’t have as much “oomph” as the ones listed already. I fear that I am unable to see many of the “problems” with Git’s methodology and workflow, because I had the (un?)fortunate experience of learning Git as my first and only VCS. I learned concepts like the index, rebasing, committing, amending, branching, merging, pulling, and pushing all for the first time from Git. I also learned how to use Git by typing the core Git commands into a terminal (since I’m in there all the time anyway), so I have not been biased in favor of GUI-only operation (these days, tig is the only GUI tool I use — and only as a brief sanity check at that). Then again, I’ve never suffered data corruption, lost branches, or anything like that, so I’m probably doing things the right way in this whole VCS thingamajig.

Oh, and here are some aliases I use for Git:

alias g='git'
alias gdf="[[ \$(git diff | wc -l) -gt 0 ]] && git diff || echo No changes"
alias gdfc="[[ \$(git diff --cached | wc -l) -gt 0 ]] && git diff --cached || echo Index empty"
alias gst='git status'
alias gbr='git branch'
alias gcm='git commit'
alias gco='git checkout'
alias glg='git log'
alias gpl='git pull'
alias gps='git push'

Some thoughts on Emacs and Vim

This post shows a couple differences between Emacs and Vim.

Now, before I begin, I’d like to say that the only reason why I recently started using Emacs along with Vim is because of Emacs’ org-mode. It is a very powerful outlining platform that really takes advantage of Emacs’ Lisp architecture (well, all Emacs extensions, by design, enjoy the powerful Lisp backend). I’ve started using org-mode recently to act as my digital planner.

Also, I’m a die-hard Vim user, so I am obviously biased.

Cool things about Emacs:

  • Lisp backend (it makes Emacs verrry powerful, perhaps too powerful (see “cons” below)): Emacs is not a text editor. It is a Lisp interpreter, that happens to be used primarily as a text editor. Org-mode, as I mentioned above, is an Emacs extension that really makes Emacs shine.
  • Command-based keybindings: In Vim, keybindings resemble macros, like this:
nmap <F1> :up<CR>

where “:up” is the actual keys that need to be pressed by the user to achieve the affect you want (here, :up and pressing ENTER results in saving a document). In Emacs, instead of specifying the literal key presses, you describe which commands are called on by the keys. So for me, I have

(global-set-key "\C-cl" 'org-store-link)

which maps “CTRL-c, l” to the org-store-link function. You can of course do the same thing in Vim by just calling a Vimscript function for some particular keybinding, but check this out: in Emacs you can easily compose multiple-function hotkeys by defining a big blank function (aka “lambda expression” or “closure”) that is made up of smaller regular functions, like so:

(global-set-key "\C-cl" (lambda ()
                     (function1)
                     (function2)
                     (function3)
                     (function4)
                        ...
                     (functionN)
                     ))

How cool is that? This is yet another example where the Lisp backend makes this possible, and so easy. I actually prefer Emacs’ way of calling the functions/commands directly like this, as it makes keybindings much easier to understand and just sticks to a simple, uniform layout: make keys call either 1 or more functions.

  • Better speed: By speed, I’m judging 3 common areas: startup time, parenthesis matching, and syntax highlighting. Emacs wins 2 out of 3. Here is the breakdown:
  • Startup time: Vim is faster (GVim is faster than Emacs, and console vim starts *instantly* whereas console emacs takes a couple seconds). CORRECTION (Feb 17, 2011): Emacs’ startup time depends on two factors (how you write your ~/.emacs file, and whether you run it as a client of a long-running emacs daemon).
  • Parenthesis matching: Emacs is lightyears ahead. Sadly, Vim slows down to a deathly crawl whenever I edit non-trivial LaTeX files, because whenever I move my cursor around (e.g., by holding down the h/l keys), it re-calculates the matching parenthesis/bracket/brace for every cursor position. Emacs chews up matching parenthesis highlighting in realtime, even for my slowest (on Vim) LaTeX documents. Again, Emacs is lightyears ahead here.
  • Syntax highlighting: Emacs’ syntax highlighting is much faster, and does not slow down *at all* even with my heaviest LaTeX files. Vim slows down to a crawl for some of my LaTeX documents when I hold down the h/l/j/k keys for incremental navigation.
  • Of course, Vim’s Normal mode makes editing files a breeze compared to Emacs’ clunky CTRL CTRL CTRL META META hotkey insanity. But Emacs is not a modal editor, so that’s why I didn’t include it in the breakdown above.

Some Emacs cons:

  • It’s not modal. This is a huuuuuuuuuge issue for me. The *best* complaint against modal editing, from what I gather from the endless Emacs vs. Vim debate, is “Vim users have to keep reaching up to the ESC key with their left pinky every 5 seconds, and the ESC key is too far away from the home row — the same home row that Vimmers proudly call their home!”. And to this complaint, I have two practical answers:
  1. Use the built-in, default CTRL-[ shortcut instead of ESC. (For some reason, this is a big mystery to both Emacs and Vim users alike.)
  2. Map “jk” to ESC. These two keys are: on the home row (and if you learned how to type, your fingers are already on these keys), are faster to type (faster than “jj” or “kk” because in those cases you only use a single finger whereas with “jk” you use two), and almost never come up in English/programming. This is what I do; I never use the ESC key.
  • Emacs’s Lisp backend makes it too powerful for its own good. Because “extending Emacs” really means “writing Lisp programs”, Emacs has become something of an OS. There are many Emacs users out there who use it as their text editor, as well as: an email/news reader, a PDF viewer, a web browser, version control management system, encryption/decryption mechanism, etc. This bizarre agglomeration of various programs all into Emacs makes it very bulky, and I suspect it is this bulkiness that slows down its startup time (although, as stated above, its parenthesis matching and syntax highlighting speed is lightning fast). CORRECTION (Feb 17, 2011): Actually, the startup time is very fast if my ~/.emacs config file is blank, but apparently my modest, relatively new ~/.emacs file loads up various plugins (Vimpulse and a color theme, among others) which slow the startup time down by a couple seconds.

That’s it! If Emacs were modal, then I would probably immediately switch to it. Currently, I use Emacs + Vimpulse whenever I need to use Org-mode (the fact that Vimpulse and Org-mode, two independent Emacs projects, work seamlessly side-by-side, emphasizes Emacs’ rich versatility). For all real text editing needs, I use Vim. Vim’s Normal mode lets me fly around a document like one of those crazy Harry Potter kids in a quidditch game.

What I don’t like about Vim:

  • Vimscript: Vimscript is just painful to use for me. It’s a scripting language but it doesn’t even have case/switch statements. All functions must start with a capital letter. Yuck! Customizing/extending Emacs with Emacs Lisp is a dream compared to working with Vimscript.

That’s about it, apart from the parenthesis/syntax speed issues noted above. I am a die-hard Vim user, by choice.

UPDATE Feb 17, 2011: Wow, apparently this post got over 3k views today, because of referrals from (among others) HackerNews and Reddit. I’ll look over the discussions at those sites and post my thoughts on here, to “fill in the holes” in my original post, so to speak. Stay tuned.

UPDATE Feb 17, 2011: So here’s the update after reflecting on some of the comments from HN and Reddit:

HN:

  • slysf says “The biggest con about emacs that’s not mentioned is that it’s just not _everywhere_.” Yeah, I’m just a hobbyist programmer so I have not had to deal with sysadmin/remote client issues. But it’s obviously a big bonus if you can use your editor of choice everywhere you go. Emacs’ saving grace is that it IS very portable, just that it’s not installed on every UNIX-y box out there by default…
  • d0mine mentions that Python doesn’t have case/switch statements as well. Holy cow, I did not know that! And apparently, you can just use Python’s dictionary type to achieve what case/switch statements do. Ruby has case/when statements (same thing as switch/case), and I used them before many times, so I just found it strange when I tried to use Vimscript and there was no such construct. However, I’ve learned that Vimscript also has a dictionary type, so, like Python, I’m sure it can be used to emulate switch/case statements. Still, in the big picture of things, Vimscript’s power will always be dwarfed by larger, more mature languages that get beaten, abused, and tested by armies of professional developers; and this is why Vimscript will always be inferior: there aren’t that many users who pound on it daily and work to develop it. Vimscript is sort of like an island on its own, while Emacs Lisp has excellent lineage (it’s a LISP dialect).

Reddit:

  • jaybee mentions that startup times really has to do with what’s in your init file. This statement is very true, and has already been incorporated in my original post as a correction. The fact that you can also run emacs as a server on boot and just launch clients instantaneously is very valuable advice. I will heed to it!
  • sping says that he just uses one emacs window (frame) and works within it. As an XMonad user on a dual head, I like using multiple windows so much that I just use multiple windows, shells, etc. all the time. If you’re on Gnome or KDE, with no tiling window manager, then sping’s method would be superior in terms of speed (no mouse dependancy). I think there are legions of Emacs users out there who started using it before the advent of popular tiling window managers, and got used to the notion of “do everything within Emacs” so much that they never bothered to try out tiling window managers (and the benefits they bring — lightning fast window navigation/management, which makes using multiple shells/programs a breeze).
  • sping also says “I have never yet read someone talking about vim who has actually made a good case for any superiority over Emacs in any significant area.” And my answer is: modal editing. Modal editing is a killer feature that Emacs is sorely missing. sping also says “I’m not actually against its modal nature, but I’m still waiting to find out exactly how it’s so f’ing awesome in ways which Emacs isn’t.” Hmm, what part of “modal editing makes navigation verrry fast” did I make unclear? I even made a Harry Potter reference, for goodness’ sake! Well, if you don’t care about fast cursor movement around, inside a file, then Vim has very little, if *any*, advantages over vanilla Emacs (the only “neat” thing I can think of is Visual Block mode, but that’s it). To be fair, sping is a former vi user, so he finds the whole modal editing thing not very impressive. To each his own.
  • Just to expand more on sping’s comment about how he has yet to find anything in Vim that is so great over Emacs, I think he’s asking fundamentally the wrong question. Vim will never really have more “awesome ways” that make it superior over Emacs, because Vim is just a text editor. And Emacs is waaaay more than a text editor. So feature-wise, Emacs will always win. However, if you’re only comparing text editing vs. text editing, then I will re-iterate that Vim’s (only real) killer feature over Emacs is modal editing (and super-fast intra-file navigation).
  • zck asks “Wouldn’t [pressing “jk”] just move the cursor up and then down?” Well, no. First, we are talking about going from Insert mode to Normal mode. If you’re already in Normal mode, then duh: your cursor will move up and then down. But since we are in Insert mode, and have “jk” insert-mode-mapped to ESC (imap jk <ESC>), every time you press j, Vim starts a little timer and sees if you press k next, and if you do indeed press k next, you escape into Normal mode. This timer is customizable, and I have it at 1 second.

Other thoughts:

On navigation speed: There are still people asking: “Is Vim really faster to navigate around a file than Emacs?” And my answer is: the hotkeys speak for themselves. (Vim is lightyears ahead.) Oh, and I also mapped the Space and Backspace keys in Normal mode like this:

nnoremap <space> 10jzz
nnoremap <backspace> 10kzz

to make navigation even faster. (You should all customize Space/Backspace keys because by default they just do what l/h do.) UPDATE March 2, 2011: Oh, and if you are using vimpulse.el (version 0.5), you can do:

; simulate vim's "nnoremap <space> 10jzz"
(vimpulse-map " " (lambda ()
                     (interactive)
                     (next-line 10)
                     (viper-scroll-up-one 10)
                     ))
; simulate vim's "nnoremap <backspace> 10kzz"
(define-key viper-vi-global-user-map [backspace] (lambda ()
                     (interactive)
                     (previous-line 10)
                     (viper-scroll-down-one 10)
                     ))

to get the same behavior.

UPDATE Feb 17, 2011: Oh, and another thing: for years some people have wanted a “breakindent” (aka “soft wrap”) feature in Vim (i.e., make it so that a very long line gets a virtual indent for all successive “lines”, such that you end up with a neat, clean rectangle for a long line that has been indented at the very beginning).  See this page and this page. Among other things, a breakindent feature would make outlines look very clean, with neat rectangular blocks for lines that start out at a deep indent. Sadly, I don’t imagine breakindent becoming a feature in Vim in the foreseeable future. In Emacs’ org-mode, breakindent is availble! Just put “#+STARTUP: indent” at the top of the .org file you are working on, and voila: sane line wrapping for outlines.

UPDATE August 5, 2011: I’ve recently switched to using the emacs –daemon and emacsclient command. Basically, I have a emacs –daemon & in my ~/.xinitrc, and then I use emacsclient -nw and emacsclient -c instead of emacs -nw and emacs, respectively. The startup times of emacsclient is near-instant — very impressive! The only drawbacks are that the emacs daemon process takes up 37MB on my system (but then again, with machines using gigabytes of RAM these days, it’s a nonissue), and you have to fiddle a bit with your ~/.emacs file to load up the correct font and color scheme (since emacs –daemon does not read the ~/.emacs file like regular standalone emacs with regard to the X11 options; see http://www.tychoish.com/rhizome/getting-emacs-daemon-to-work-right/ and http://old.nabble.com/–daemon-vs.-server-start-td21594587.html).

I’ve also dropped Vimpulse in favor of Evil, since the core developer for it (Vegard Øye) decided to join forces with another Vim-minded emacs extension author (Frank Fischer, of vim-mode) to create a newer, better Vim emulation layer earlier in February this year (just 10 days after the date of my original post!). See http://news.gmane.org/find-root.php?group=gmane.emacs.vim-emulation&article=692. Anyway, the official Evil repo is at http://gitorious.org/evil/ (more info at http://gitorious.org/evil/pages/Home). The only drawback right now is that Evil does not currently emulate Vi’s Ex mode (in Vim, when you type the colon ‘:’ character from Normal mode). If you really want this feature right now, too, then I suggest cloning from Frank Fischer’s personal branch, at https://bitbucket.org/lyro/evil/overview, which includes Ex mode. I suspect that Fischer’s Ex-mode code will be merged into Evil sometime in the future since Fischer keeps his branch in sync with the official Evil repo.

The best part about using Evil is that it does not depend on Viper, the old Vi extension for emacs.

Anyway, here’s how I’ve set up Evil in my ~/.emacs (many of these keymaps only make sense if you’re in org-mode, but whatever):

; evil, the Extensible VI Layer! seee http://gitorious.org/evil/pages/Home
(add-to-list 'load-path "~/.emacs.d/script/evil")
(require 'evil)
(evil-mode 1)
; some keymaps from ~/.vimrc
(define-key evil-insert-state-map [f1] 'save-buffer) ; save
(define-key evil-normal-state-map [f1] 'save-buffer) ; save
(define-key evil-normal-state-map ",w" 'save-buffer) ; save
(define-key evil-normal-state-map ",q" 'kill-buffer) ; quit (current buffer; have to press RETURN)
(define-key evil-normal-state-map ",x" 'save-buffers-kill-emacs) ; save and quit
; make "kj" behave as ESC key ,adapted from http://permalink.gmane.org/gmane.emacs.vim-emulation/684
; you can easily change it to map "jj" or "kk" or "jk" to ESC)
(defun escape-if-next-char (c)
    "Watches the next letter.  If c, then switch to Evil's normal mode; otherwise insert a k and forward unpressed key to unread-command events"
      (self-insert-command 1)
        (let ((next-key (read-event)))
              (if (= c next-key)
                        (progn
                                    (delete-backward-char 1)
                                              (evil-esc))
                              (setq unread-command-events (list next-key)))))

(defun escape-if-next-char-is-j (arg)
    (interactive "p")
      (if (= arg 1)
              (escape-if-next-char ?j)
                  (self-insert-command arg)))

(define-key evil-insert-state-map (kbd "k") 'escape-if-next-char-is-j)
; simulate vim's "nnoremap <space> 10jzz"
(define-key evil-normal-state-map " " (lambda ()
                     (interactive)
                     (next-line 10)
                     (evil-scroll-line-down 10)
                     ))
; simulate vim's "nnoremap <backspace> 10kzz"
(define-key evil-normal-state-map [backspace] (lambda ()
                     (interactive)
                     (previous-line 10)
                     (evil-scroll-line-up 10)
                     ))

; make evil work for org-mode!
(define-key evil-normal-state-map "O" (lambda ()
                     (interactive)
                     (end-of-line)
                     (org-insert-heading)
                     (evil-append nil)
                     ))

(defun always-insert-item ()
     (interactive)
     (if (not (org-in-item-p))
       (insert "\n- ")
       (org-insert-item)))

(define-key evil-normal-state-map "O" (lambda ()
                     (interactive)
                     (end-of-line)
                     (org-insert-heading)
                     (evil-append nil)
                     ))

(define-key evil-normal-state-map "o" (lambda ()
                     (interactive)
                     (end-of-line)
                     (always-insert-item)
                     (evil-append nil)
                     ))

(define-key evil-normal-state-map "t" (lambda ()
                     (interactive)
                     (end-of-line)
                     (org-insert-todo-heading nil)
                     (evil-append nil)
                     ))
(define-key evil-normal-state-map (kbd "M-o") (lambda ()
                     (interactive)
                     (end-of-line)
                     (org-insert-heading)
                     (org-metaright)
                     (evil-append nil)
                     ))
(define-key evil-normal-state-map (kbd "M-t") (lambda ()
                     (interactive)
                     (end-of-line)
                     (org-insert-todo-heading nil)
                     (org-metaright)
                     (evil-append nil)
                     ))
(define-key evil-normal-state-map "T" 'org-todo) ; mark a TODO item as DONE
(define-key evil-normal-state-map ";a" 'org-agenda) ; access agenda buffer
(define-key evil-normal-state-map "-" 'org-cycle-list-bullet) ; change bullet style

; allow us to access org-mode keys directly from Evil's Normal mode
(define-key evil-normal-state-map "L" 'org-shiftright)
(define-key evil-normal-state-map "H" 'org-shiftleft)
(define-key evil-normal-state-map "K" 'org-shiftup)
(define-key evil-normal-state-map "J" 'org-shiftdown)
(define-key evil-normal-state-map (kbd "M-l") 'org-metaright)
(define-key evil-normal-state-map (kbd "M-h") 'org-metaleft)
(define-key evil-normal-state-map (kbd "M-k") 'org-metaup)
(define-key evil-normal-state-map (kbd "M-j") 'org-metadown)
(define-key evil-normal-state-map (kbd "M-L") 'org-shiftmetaright)
(define-key evil-normal-state-map (kbd "M-H") 'org-shiftmetaleft)
(define-key evil-normal-state-map (kbd "M-K") 'org-shiftmetaup)
(define-key evil-normal-state-map (kbd "M-J") 'org-shiftmetadown)

(define-key evil-normal-state-map (kbd "<f12>") 'org-export-as-html)

UPDATE August 12, 2011: Great news! Frank Fischer’s Ex mode branch was merged into upstream just two days ago (commit 46447065ed5a374452504bd311b91902b8ce56d4), so now Evil has Ex mode!

Also, I noticed that Evil uses (kbd “DEL”) instead of [backspace] for binding the Backspace key (commit 8fc3c4065c7ed50a6033a7f1c68deba5a9270043), so I recommend changing the Backspace binding I posted previously to:

; simulate vim's "nnoremap <backspace> 10kzz"
(define-key evil-normal-state-map (kbd "DEL") (lambda ()
                     (interactive)
                     (previous-line 10)
                     (evil-scroll-line-up 10)
                     ))

I tested the change, and indeed, the previous binding with [backspace] was broken for console emacs, but it works with (kbd “DEL”).

UPDATE November 17, 2011: Tom (comment #19) pointed out that you can define hotkeys in a mode-specific way from within evil, as follows:

(evil-declare-key 'normal org-mode-map "T" 'org-todo)
(evil-declare-key 'normal org-mode-map "-" 'org-cycle-list-bullet)

This way, your hotkeys will not collide if you change modes. (Not a problem for me because I only use emacs for org-mode, but there you have it.)

Oh, and the old “kj” escape key function no longer works; here is the new version:

(define-key evil-insert-state-map "k" #'cofi/maybe-exit)

(evil-define-command cofi/maybe-exit ()
  :repeat change
  (interactive)
  (let ((modified (buffer-modified-p)))
    (insert "k")
    (let ((evt (read-event (format "Insert %c to exit insert state" ?j)
			   nil 0.5)))
      (cond
       ((null evt) (message ""))
       ((and (integerp evt) (char-equal evt ?j))
	(delete-char -1)
	(set-buffer-modified-p modified)
	(push 'escape unread-command-events))
       (t (setq unread-command-events (append unread-command-events
					      (list evt))))))))

The original source is at http://article.gmane.org/gmane.emacs.vim-emulation/980. What’s great about this version is that it behaves almost exactly like the original vim mapping; once you type “k”, you have a 0.5-second window to type in “j” to escape — otherwise, you just get “k” on the screen.

UPDATE March 7, 2012: For a long time, I did not realize that the “10<c-e>10j” keybinding for <space> was not what I wanted, as it moved the cursor more than 10 lines down (<c-e> is an “impure” way to scroll). The proper way is to use “zz”, which resets the screen to have the cursor in the middle of the screen (vertically), without changing the current line position.

On Exercise

I started exercising regularly again. I’ve taken a new approach to exercise:

  • Exercise is not about losing weight.
  • Exercise is not about toning one’s physique.
  • Exercise is not about staying healthy.

Although exercise does help one lose weight, tone one’s physique, and stay healthy, these things are mere side effects of exercise. Exercise results in the strengthening of one’s mental fortitude. Real, tough, in-the-guts exercise requires a truckload of willpower. Each time we exercise, we train on a mental level.

Take elite athletes as an example. Day in and day out, they train. With time, they gain the ability to maintain an incredible amount of mental focus under an incredible amount of stress. And when they compete, they are able to perform what their sport requires of them, even when they’re hurting.

Everyone hopes they could do X, Y, and Z to make improvements in their lives. Without mental discipline, they are going to waste a lot of time. Maybe this realization, on a subconscious level, gives them an incentive to procrastinate.

In short, exercise strengthens the mind. It is the most simple, yet important, thing that I can do to improve all areas of my life.

Latex: Saner Source Code Listings: No Starch Press Style

I’ve lately gotten in the habit of writing aesthetically pleasing ebooks with LaTeX for myself on new subjects that I come across. This way, I can (1) learn more about TeX (always a huge bonus) and (2) create documents that are stable, portable (PDF output), beautiful, and printer-friendly. (I also put all the .tex and accompanying makefiles into version control (git) and sync it across all of my computers, to ensure that they last forever.)

One of those new subjects for me right now is the Haskell programming language. I started copying down small code snippets from various free resources on the web, with the help of the Listings package (actually named the lstlisting package internally).

The Problem

Unfortunately, I got tired of referencing line numbers manually to explain the code snippets, like this:

\documentclass[twoside]{article}
\usepackage[x11names]{xcolor} % for a set of predefined color names, like LemonChiffon1

\newcommand{\numold}[1]{{\addfontfeature{Numbers=OldStyle}#1}}
\lstnewenvironment{csource}[1][]
    {\lstset{basicstyle=\ttfamily,language=C,numberstyle=\numold,numbers=left,frame=lines,framexleftmargin=0.5em,framexrightmargin=0.5em,backgroundcolor=\color{LemonChiffon1},showstringspaces=false,escapeinside={(*@}{@*)},#1}}
    {}

\begin{document}
\section{Hello, world!}
The following program \texttt{hello.c} simply prints ``Hello, world!'':

\begin{csource}
#include <stdio.h>

int main()
{
    printf("Hello, world!\n");
    return 0;
}
\end{csource}

At line 1, we include the \texttt{stdio.h} header file. We begin the \texttt{main} function at line 3. We print ``Hello, world!'' to standard output (a.k.a., \textit{STDOUT}) at line 5. At line 6, we return value 0 to let the caller of this program know that we exited safely without any errors.
\end{document}

Output (compiled with the xelatex command):
Plain lstlisting style

This is horrible. Any time I add or delete a single line of code, I have to manually go back and change all of the numbers. On the other hand, I could instead use the \label{labelname} command inside the lstlisting environment on any particular line, and get the line number of that label with \ref{comment}, like so:

\section{Hello, world!}
The following program \texttt{hello.c} simply prints ``Hello, world!'':

\begin{csource}
#include <stdio.h>(*@\label{include}@*)

int main()(*@\label{main}@*)
{
    printf("Hello, world!\n");(*@\label{world}@*)
    return 0;(*@\label{return}@*)
}
\end{csource}
At line \ref{include}, we include the \texttt{stdio.h} header file. We begin the \texttt{main} function at line \ref{main}. We print ``Hello, world!'' to standard output (a.k.a., \textit{STDOUT}) at line \ref{world}. At line \ref{return}, we return value 0 to let the caller of this program know that we exited safely without any errors.

Output:

(The only difference is that the line number references are now red. This is because I also used the hyperref package with the colorlinks option.)

But I felt like this was not a good solution at all (it was suggested by the official lstlisting package’s manual, Section 7 “How tos”). For one thing, I have to think of a new label name for every line I want to address. Furthermore, I have to compile the document twice, because that’s how the \label command works. Yuck.

Enlightenment

So again, with my internet-research hat on, I tried to figure out a better solution. The first thing that came to mind was how the San Francisco-based publisher No Starch Press displayed source code listings in their newer books. Their stylistic approach to source code listings is probably the most sane (and beautiful!) one I’ve come across.

After many hours of tinkering, trial-and-error approaches, etc., I finally got everything working smoothly. Woohoo! From what I can tell, my rendition looks picture-perfect, and dare I say, even better than their version (because I use colors, too). Check it out!

\documentclass{article}
\usepackage[x11names]{xcolor} % for a set of predefined color names, like LemonChiffon1
\newcommand{\numold}[1]{{\addfontfeature{Numbers=OldStyle}#1}}
\usepackage{libertine} % for the pretty dark-circle-enclosed numbers

% Allow "No Starch Press"-like custom line numbers (essentially, bulleted line numbers for only those lines the author will address)
\newcounter{lstNoteCounter}
\newcommand{\lnnum}[1]
    {\ifthenelse{#1 =  1}{\libertineGlyph{uni2776}}
    {\ifthenelse{#1 =  2}{\libertineGlyph{uni2777}}
    {\ifthenelse{#1 =  3}{\libertineGlyph{uni2778}}
    {\ifthenelse{#1 =  4}{\libertineGlyph{uni2779}}
    {\ifthenelse{#1 =  5}{\libertineGlyph{uni277A}}
    {\ifthenelse{#1 =  6}{\libertineGlyph{uni277B}}
    {\ifthenelse{#1 =  7}{\libertineGlyph{uni277C}}
    {\ifthenelse{#1 =  8}{\libertineGlyph{uni277D}}
    {\ifthenelse{#1 =  9}{\libertineGlyph{uni277E}}
    {\ifthenelse{#1 = 10}{\libertineGlyph{uni277F}}
    {\ifthenelse{#1 = 11}{\libertineGlyph{uni24EB}}
    {\ifthenelse{#1 = 12}{\libertineGlyph{uni24EC}}
    {\ifthenelse{#1 = 13}{\libertineGlyph{uni24ED}}
    {\ifthenelse{#1 = 14}{\libertineGlyph{uni24EE}}
    {\ifthenelse{#1 = 15}{\libertineGlyph{uni24EF}}
    {\ifthenelse{#1 = 16}{\libertineGlyph{uni24F0}}
    {\ifthenelse{#1 = 17}{\libertineGlyph{uni24F1}}
    {\ifthenelse{#1 = 18}{\libertineGlyph{uni24F2}}
    {\ifthenelse{#1 = 19}{\libertineGlyph{uni24F3}}
    {\ifthenelse{#1 = 20}{\libertineGlyph{uni24F4}}
    {NUM TOO HIGH}}}}}}}}}}}}}}}}}}}}}
\newcommand*{\lnote}{\stepcounter{lstNoteCounter}\vbox{\llap{{\lnnum{\thelstNoteCounter}}\hskip 1em}}}
\lstnewenvironment{csource2}[1][]
{
    \setcounter{lstNoteCounter}{0}
    \lstset{basicstyle=\ttfamily,language=C,numberstyle=\numold,numbers=right,frame=lines,framexleftmargin=0.5em,framexrightmargin=0.5em,backgroundcolor=\color{LemonChiffon1},showstringspaces=false,escapeinside={(*@}{@*)},#1}
}
{}

\begin{document}
\section{Hello, world!}
The following program \texttt{hello.c} simply prints ``Hello, world!'':

\begin{csource2}
(*@\lnote@*)#include <stdio.h>

/* This is a comment. */
(*@\lnote@*)int main()
{
(*@\lnote@*)    printf("Hello, world!\n");
(*@\lnote@*)    return 0;
}
\end{csource2}

We first include the \texttt{stdio.h} header file \lnnum{1}. We then declare the \texttt{main} function \lnnum{2}. We then print ``Hello, world!'' to standard output (a.k.a., \textit{STDOUT}) \lnnum{3}. Finally, we return value 0 to let the caller of this program know that we exited safely without any errors \lnnum{4}.
\end{document}

Output (compiled with the xelatex command):

Ah, much better! This is pretty much how No Starch Press does it, except that we’ve added two things: the line number count on the right hand side, and also a colored background to make the code stand out a bit from the page (easier on the eyes when quickly skimming). These options are easily adjustable/removable to suit your needs (see line 33). For a direct comparison, download some of their sample chapter offerings from Land of Lisp (2010) and Network Flow Analysis (2010) and see for yourself.

Explanation

If you look at the code, you can see that the only real thing that changed in the listing code itself is the use of a new \lnote command. The \lnote command basically spits out a symbol, in this case whatever the \lnnum command produces with the value of the given counter, lstNoteCounter. The \lnnum command is basically a long if/else statement chain (I tried using the switch statement construct from here, but then extra spaces would get added in), and can produce a nice glyph, but only up to 20 (for anything higher, it just displays the string “NUM TOO HIGH.” This is because it uses the Linux Libertine font to create the glyph (with \libertineGlyph), and Libertine’s black-circle-enclosed numerals only go up to 20). A caveat: Linux Libertine’s LaTeX commands are subject to change without notice, as it is currently in “alpha” stage of development (e.g., the \libertineGlyph command actually used to be called the \Lglyph command, if I recall correctly).

The real star of the show is the \llap command. I did not know about this command until I stumbled on this page yesterday. For something like an hour I toiled over trying to use \marginpar or \marginnote (the marginnote package) to get the same effect, without success (for one thing, it is impossible to create margin notes on one side (e.g., always on the left, or always on the right) if your document class is using the twoside option.

The custom \numold command (used here to typeset the line numbers with old style figures) is actually a resurrection of a command of the same name from an older, deprecated Linux Libertine package. The cool thing about how it’s defined is that you can use it with or without an argument. Because of this \numold command and how it’s defined, you have to use the XeTeX engine (i.e., compile with the xelatex command).

In all of my examples above, the serif font is Linux Libertine, and the monospaced font is DejaVu Sans Mono.

Other Thoughts

You may have noticed that I have chosen to use my own custom lstlisting environment (with the \lstnewenvironment command). The only reason I did this is because I can specify a custom command that starts up each listing environment. In my case, it’s \setcounter{lstNoteCounter}{0}, which resets the notes back to 0 for the listing.

Feel free to use my code. If you make improvements to it, please let me know! By the way, Linux Libertine’s latex package supports other enumerated glyphs, too (e.g., white-circle-enclosed numbers, or even circle-enclosed alphabet characters). Or, you could even use plain letters enclosed inside a \colorbox command, if you want. You can also put the line numbers right next to the \lnote numbers (we just add numbers=left to the lstnewenvironment options, and change \lnote’s hskip to \2.7em; I also changed the line numbers to basic italics):

\lstnewenvironment{csource2}[1][]
    {\lstset{basicstyle=\ttfamily,language=C,numberstyle=\itshape,numbers=left,frame=lines,framexleftmargin=0.5em,framexrightmargin=0.5em,backgroundcolor=\color{LemonChiffon1},showstringspaces=false,escapeinside={(*@}{@*)},#1}}
    {\stepcounter{lstCounter}}

\newcommand*{\lnote}{\stepcounter{lstNoteCounter}\llap{{\lnnum{\thelstNoteCounter}}\hskip 2.7em}}

Output:

Or we can swap their positions (by using the numbersep= command to the lstnewenvironment declaration, and leaving \lnnote as-is with just 1em of \hskip):

\lstnewenvironment{csource2}[1][]
    {\lstset{basicstyle=\ttfamily,language=C,numberstyle=\itshape,numbers=left,numbersep=2.7em,frame=lines,framexleftmargin=0.5em,framexrightmargin=0.5em,backgroundcolor=\color{LemonChiffon1},showstringspaces=false,escapeinside={(*@}{@*)},#1}}
    {\stepcounter{lstCounter}}

Output:

The possibilities are yours to choose.

In case you’re wondering, the unusual indenting of the section number into the left margin in my examples is achieved as follows:

\usepackage{titlesec}
\titleformat{\section}
    {\Large\bfseries} % formatting
    {\llap{
       {\thesection}
       \hskip 0.5em
    }}
    {0em}% horizontal sep
    {}% before

It’s a simplified version of the code posted on the StackOverflow link above.

NB: The \contentsname command (used to render the “Contents” text if you have a Table of Contents) inherits the formatting from the \chapter command (i.e., if you use \titleformat{\chapter}). Thus, if you format the \chapter command like the \section command above with \titleformat, the only way to prevent this inheritance (if it is not desired) is by doing this:

\renewcommand\contentsname{\normalfont Contents}

This way, your Table of Content’s title will stay untouched by any \titleformat command.

UPDATE December 7, 2010: Some more variations and screenshots.