As an experiment, I have recently started using Vim as my primary text editor. While I have been an Emacs aficionado for a very, very long time – clocking in at almost 16 years – Vim is something that I have always been curious about, and tinkered with from time to time, while ending up going back to Emacs. This time however, I intend to stick around for a while, and try to get a feel of the Zen of Vim.

The experience with Vim has been rather pleasant so far. While  configuration is definitely a must (just like Emacs), out of the box experience is not bare bones either. In fact, the default settings are rather good, and one can get a lot of mileage from the vanilla setup.

The USP of Vim is that it is first and foremost a text editor, and does not attempt to be THE kitchen sink. In other words, its core focus is to provide the best and most functions to manipulate text; it is not to provide a universal platform where one of the applications happens to be an editor.

The Editing Model

The very first experience the user gets on launching Vim is that it is a modal editor, with distinct modes for entering text, and editing it.

This is in stark contrast to most other editors, which provide the editing functions via other mechanisms, such as menus or key chords (à la Emacs). While this might seem odd at first glance, it is definitely a key component of Vim’s power, and arguably its success as a text editor.

In addition, the second key distinguishing factor of Vim is that its editing is based on a “noun-adjective-count-movement-verb” model of editing. Nearly every editing command is a sequence of one or more of these primitives, where the intent of the edit operation is usually fully mapped to the encoding offered by various combinations of these primitives.

As an example, to move 5 lines down, and then 3 words forward, to delete the next two words, the following “primitive encoding” can be used:

      5j 3w 2de 

While this is a rather trivial example, it illustrates a key principle of using Vim – the editing model is based on MOVEMENT and MANIPULATION, explicitly and succinctly made via the modal key-chords which apply the same basic foundational model at all scales.

To a large extent, this underlying pair is what the user usually is thinking about, when an editing operation is being thought of. The primitives are just the vocabulary to tell Vim to execute the intent.

The movement itself can be further separated into raw movements (i.e., lines and characters), or be semantic oriented (words, sentences, paragraphs, functions, etc.) This can sometimes be further refined using “adjectives” such as “begin”, “end”, “between”, or “surrounded”. In addition, the count represents multiples of the movement unit being specified, and allows velocity of the movement to be increased significantly.

The verb is of course where the “real action” happens. In a general sense, every verb is really a “change” verb, with specializations of “delete”, “replace”, “convert”, etc.

Conveniences

In essence, the core feature set of Vim (and certainly its spiritual ancestor – Vi) can be adequately expressed by the core model described above.

However, a basic feature does not make a competent editor. This requires other user comforts such as multi-file edits, windowing mechanisms (including split windows), language syntax, external tool integration (spell checks, compilers, shell interaction), extensive customization to fit the user’s need, an usable in-built help system, and many more such features that make regular usage comfortable and transparent. And Vim does have all of these in abundance, with parity with Emacs in most of these areas in terms of feature completeness, and power.

Granted, Vim does not yet have an inbuilt News Reader, or an email client, but the core editing functions are very much there, or easily added via plug-ins.

Conclusions

The feeling I get from using Vim is really about efficiency and focus, while Emacs seems to exude more a sense of power. Both can be frustrating at times, often from over-abundance of features than anything else, and hidden functionality that takes years to internalize before returns are gained.

Vim and Emacs are both excellent editors, and share a lot in common. The complexity, feature-richness, and the high learning curve are the ones that stand out the most. Also, the vibrant community around both editors is a shared characteristic.

Editor wars aside, both are very competent and complex pieces of software, and will serve the user well, provided an investment is made in learning the unique interfaces that both exhibit.

As for me, I do not anticipate leaving the Emacs bandwagon any time soon — especially with significant investments now in the Orgmode work-flow that I have built up over the past few years. However, I do see Vim as another pro-tool in my toolbox, which is definitely going to get a lot more love and use in the days ahead.

The longer story requires more explanation …

The Problem

I have been looking forward to upgrading to the latest version of OSX (Lion) ever since the announcements were made in the WWDC earlier this year.

However, in the middle of the whole slew of new functions and features (“250+”), Lion is also leaving behind a few things – notably Rosetta (the PowerPC translation layer) – and the iSync and FrontRow applications.

The demise of PowerPC emulation has been long in coming, and was not really a surprise, given that it has been 6 years since Intel became the official CPU for Apple machines. The main impact really seems to be for Quicken users, which might actually be a blessing in disguise, given how pathetic Quicken really was on the Mac.

iSync has been removed presumably because it has been one of the “low usage” applications on the platform. iTunes is the center of most of the Mac based synchronization these days, along with MobileMe for the cloud side of things.

However, iSync has been a key feature of the OS for me, as I carry a non-iOS phone (a Nokia E71 actually), and being able to seamlessly synchronize my contacts and calendars with the phone using iSync made it a key part of my workflow (I even have some Automator scripts to make this easier). And iSync has been able to synchronize over Bluetooth, unlike the tethered experience with the iOS devices so far (though OTA sync is on the way with iOS 5 later this fall).

Alas, OS X Lion removes the iSync application from the hard disk once it is installed, and for a time I thought that this was end of the line for the convenience I had with the E71, and would need to go back to the darks days of manual data entry for the addresses (manual entry of calendar entries is too much of a hassle on the phone, and would need to be dropped all together).

The Solution

Before installation of Lion, I had taken a full disk image of my previous Snow Leopard installation using the excellent SuperDuper! Disk cloner.

This was more from a backup and recovery perspective, but allowed me an unexpected solution to the iSync quandary – on a whim, I attached the Snow Leopard disk to the Mac running Lion, and clicked on the iSync application. Voila! iSync works exactly as it should!

In hindsight, this is not really surprising, since iSync really has been a front end for the underlying sync services (which are still around in Lion), and for managing phone and device specific plugins.

All that was needed was to just copy over iSync back into the “/Applications” folder, and also copy the phone plugins (just one in my case) to the “/Library/PhonePlugins” folder.

In summary, while Apple in its immense wisdom took out a feature that was useful to some (albeit a minority), getting it to work again was surprisingly easy. Will need to check out the situation with FrontRow next time.

[Update on July 22, 2011]

Looks like a similar recovery process exists for FrontRow as well.  See this article at Macworld.

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 7,800 times in 2010. That’s about 19 full 747s.

In 2010, there were 9 new posts, growing the total archive of this blog to 33 posts. There were 14 pictures uploaded, taking up a total of 941kb. That’s about a picture per month.

The busiest day of the year was March 30th with 408 views. The most popular post that day was Converting from TaskPaper to Emacs Org-Mode.

Where did they come from?

The top referring sites in 2010 were planet.emacsen.org, Google Reader, twitter.com, joelgreutman.wordpress.com, and google.com.

Some visitors came searching, mostly for aquaterm snow leopard, gnuplot aquaterm snow leopard, aquaterm 64bit, gnuplot snow leopard, and gnuplot aquaterm.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Converting from TaskPaper to Emacs Org-Mode March 2010
12 comments

gnuplot with AquaTerm on OSX Snow Leopard January 2010
8 comments and 1 Like on WordPress.com,

Importing contacts from OSX Addressbook to Emacs BBDB August 2009
3 comments

Emacs function to add new path elements to the $PATH environment variable January 2010
1 comment

Tips for using emacsclient and server-mode on OSX August 2009
2 comments

Seriously. I have been a long proponent and user of Firefox, having been lured into it by its relative elegance and the extension framework many moons back. Also, the web development support has always been far better than its competition, with Firebug and Web Developer to name just two great reasons for it being the developer’s browser of choice.

The sheer number of Firefox add-ons and extensions (about 13,000 in the last count) is staggering – and list absolute essentials such as Adblock Plus, XMarks and DownThemAll! This combined with the themes (I suggest GrApple Yummy on the Mac) has been making the web browsing experience a far better one for me than Safari.

But the problem with Firefox is … it is SLOW.

With just seven add-ons (Adblock Plus, XMarks, DownThemAll!, 1Password, LastPass, FlashBlock and Firefox PDF Plugin for Mac OS X) it takes about 3-4 seconds to launch the application opening a blank home page on an OS X 10.6.3 MacBook. Another 2-3 seconds before any reasonable page is fully rendered. This becomes excruciatingly slow when I am busily opening tabs from a RSS reader or another application – and frustrating when it has to launch the first time I click on a link in another application.

Also, while a custom theme does look pretty – it sometimes does expose artifacts in the chrome (no pun intended) when rendering new pages – especially in the “awesome bar”.

All in all, while the experience is nice, it certainly is not perfect. Speed of launch and rendering are the main gripes.

I have been toying with Google Chrome ever since the beta for OS X came out. I was initially put off by the inverted tabs as well as lack of extensions (hey, a 21st century browser with no extensions, come on!) Also, the single URL bar/search bar UI seemed … odd. So while the beta version did stay on the HDD, it did not see much use, and Firefox remained the work horse for daily use.

However, with the recent launch of the stable OS X version, I became interested again. And this time Chrome did have a pretty mature extensions ecosystem, some of which seemed to be reasonable replacements for the Firefox equivalents. Time for a spin!

The first thing which struck me was the speed of launch as well as page renders, and the UI feels much more “fluid”. The Inverted tabs still look odd and out of place, but I understand the need to squeeze the additional 20-30 pixels for actual page use.

Actual page rendering in terms of quality is more or less at par with Firefox, though a few oddball sites (especially the work related sites) sometimes get weird effects. I blame it on the IE centric development though.

The unified bar is also starting to make sense, as it actually helps in not having to remember one extra key short cut for searching. It has good support for Firefox like keyword searches as well (example, ‘wk’ for Wikipedia searches) provided you set them up.

I also found more or less feature equivalent extensions:

Xmarks is available for Chrome
Lastpass is available for Chrome
AdThwart in replacement of AdBlock Plus

I found that FlashBlock does exist for Chrome, but I don’t really need it anymore.

The one big hole in the extensions/add-on replacement is DownThem All! There are quite a few download managers, but none can match the Firefox one in terms of features (I am still looking).

The extension manager is also pretty nice, and arguably better than the Firefox one (at least for FF 3.6.3). However, the actual extensions gallery on Google is not quite as user friendly as the Firefox one. The extensions are not categorized completely, which makes it somewhat of a pain to search and find the right one.

All in all, the Chrome experience has been a refreshing one so far, and Firefox has not seen much use of late – except where I needed to use DownThem All! (simultaneously downloading all chapters of the free audiobooks from www.librivox.org is one example). If anyone has recommendation for a good replacement, let me know.

So there you have it. My infatuation with Chrome has already lasted more than a week, and I still find it a pleasure to use. Have not really dabbled much with the extensions (and themes – Chrome does have support for these as well) – but am finding that I don’t really need to.

The source downloads are available at: ftp.gnu.org/gnu/emacs/

For those who prefer access to the VCS, the read-only bzr URL is:

http://bzr.savannah.gnu.org/r/emacs/emacs-23.

Enjoy!

TaskPaper is a simple and elegant task management software for the OSX platform. It combines the simplicity of a text micro-format to mark the tasks, and the elegance of a Mac UI. It also provides a quick launch time and a nice system-wide quick entry window that is accessible with a single shortcut key.

I have been a heavy user of Emacs’ Org-Mode for some years now, and love the power and flexibility it offers for tracking not just outlines and tasks, but any text based item, including notes and calendar entries. In fact Org-Mode has become one of the primary software that I use regularly, every day.

So where does the link between TaskPaper and Org-Mode come in? Both are text based, and have their own light-weight formats to define outlines and tasks. The underlying files are plain text with the meaning readable even when not viewed by the appropriate software. Org-Mode is obviously much more feature rich than TaskPaper, which by design keeps things simple.

However, there is one big difference that has led me to looking at integration: Org-Mode is Emacs based and hence takes ages to launch. TaskPaper on the other hand launches in under a second, and also offers a nice quick entry form that is available system-wide via a a global short-cut key.

Emacs aficionados will protest now – after all – Emacs is meant to be launched and never shutdown! This is true, but in my usage patterns, Emacs does get closed once in a while and having to launch it just to make a few quick Org-Mode entries (even with the excellent remember mode) becomes a pain.

My usage has now become more of the following:

1. Use TaskPaper as an initial capture mechanism (sort of as a pre-Inbox store). I make heavy use of the quick entry window here
2. Use a script to collect the TaskPaper entries and reformat them into a Org-Mode compatible file
3. Append the converted entries into my primary Org-Mode Inbox whenever I have Emacs open

This (for me) provides best of both worlds – quick and ubiquitous data capture, and the power and flexibility of Org-Mode.

The Ruby Conversion Script

Without further ado, the script to convert from TaskPaper to Org-mode is:

#!/usr/bin/env ruby
#
# Converts Taskpaper files to Emacs org-mode files.
#
# Author: Anupam Sengupta, 2010
#
# Distributed under the BSD license (http://www.opensource.org/licenses/bsd-license.php)
#
# Usage: From the command line, enter the command:
#
#  ./tpaper2org.rb <taskpaperfilename>
#
# The output is on STDOUT, which can be redirected to an Org-mode file.
# Whether the generated org-mode file should use odd-level prefix stars
# See http://orgmode.org/manual/Clean-view.html for details.
ORG_USES_ODD_LEVELS = false

LINE_PATTERN = /^(\t*)          # Leading tabs
               -                # Followed by a dash (the taskpaper task identifier)
               (.*?)            # The task description
               ((@\w+\s*)*)     # The tags, if any
               $/x

all_tags = Hash.new(0)

Shiftlvl = ORG_USES_ODD_LEVELS ? 2 : 1 # Determine the number of stars to use in Org-mode entries

while (line = gets()):
  line.chomp!
   md = LINE_PATTERN.match(line)          # Match and extract each line
  if md then                                                # ................ A Task line
    tags = md[3].split(/ +/).reject {|tag| “@done” == tag } # get the tags, except @done tags
    tags = [‘’, tags, ‘’].flatten unless tags.empty?
    puts ‘*’ * (1 + Shiftlvl * (md[1].length + 1)) + (line =~ /@done/ ? “ DONE” : “ TODO”) + md[2] + tags.join(‘:’)
    tags.each { |tag| all_tags[tag] += 1} if tags # Keep a list of all tags
  elsif line =~/:$/                               # ................ A project line
    print “* “
    puts line.chomp(“:”)
  else                          # ................ Any other line
    puts line
  end
end

# Lets do a summary of the tags used.
puts <<END
# The tags used till now.
#+TAGS:#{all_tags.keys.sort.join(‘ ‘)}
END

Note that Org-mode supports multiple prefix styles with ‘*’. In particular, the odd-levels versus the odd-even levels is interesting and useful. The script has a ‘ORG_USES_ODD_LEVELS’ global variable that can be set to true if this is the desired export format.

In addition, the script also adds the tags used in the TaskPaper file as a ‘#+TAGS’ entry in the exported org-mode file. You can comment this if this is not required.

The TaskPaper format

The TaskPaper format is simple, and the file (which by default ends with the extension ‘.taskpaper’) is essentially a plain text file that can be opened and edited in any text editor.

The format can be summarized as (from the TaskPaper User’s Guide):

A project is a line ending with a colon:

      A Project:

A task is a line starting with a dash followed by a space:

    - My First Task

A Note is any line that is NOT a project or a task (i.e., does not start with a dash or end with a colon):

    Notes for a task

A tag is any word prefixed with the @ symbol. The tag can optionally have a value in parentheses after the tag name:

      - My First Task @atag @another_tag(1)

Outlining is done by indenting the tasks with tabs:

     - My First Task @atag
         - My sub-level task

Usage

Using the script is simple. Assuming that TaskPaper’s file is named tasks.taskpaper, from the OS X terminal, run the following command:

        $ tpaper2org.rb tasks.taskpaper >> tinbox.org

Where tinbox.org is the destination org-mode file.

This shell command can be put into a cron job or invoked from within Emacs to pull in the tasks as required. You may also want to delete the TaskPaper file (or empty its contents) after this is done, to prevent duplicate entries being imported the next time the Ruby Script is run.

Links

taskpaper.el is an Emacs mode for emulating the TaskPaper interface with support for projects and tasks. The tags support seems to be missing.

Discussion on the Org-Mode mailing list about Taskpaper and Org-Mode.

There were a few plugins that claimed to enable this in prior versions, but never worked very well.

The option is available under the “View”menu and has a standard Apple-Shift-F shortcut as well.

(defun my-add-path (path-element)
 "Add the specified path element to the Emacs PATH"
  (interactive "DEnter directory to be added to path: ")
  (if (file-directory-p path-element)
    (setenv "PATH"
       (concat (expand-file-name path-element)
               path-separator (getenv "PATH")))))

A simple function to quickly do a diff of the current buffer contents with its underlying file. Very useful if the file has been changed outside (e.g., a log file).

;; Diff the current buffer with the file contents
(defun my-diff-current-buffer-with-disk ()
 "Compare the current buffer with it's disk file."
 (interactive)
 (diff-buffer-with-file (current-buffer)))
(global-set-key (kbd "C-c w") 'my-diff-current-buffer-with-disk)