The Other Emacsen

While Emacs remains my primary text editor, there are times when starting a full Emacs session with tons of packages is simply too slow, especially on a terminal window, and when the task at hand is simply to make a few lines of changes in a configuration file.

Yes, I do know about the handy -q command-line option, which prevents the init.el file from being loaded, thereby ensuring a sub-second initialization of Emacs, or the emacsclient route (which I have enabled, and do use), but sometimes it is just more convenient to have a fast editor that has the Emacs feel, without the bloat. And for a text nerd such as myself, it is also a matter of curiosity to try out other editors once in a while.

Emacs actually has had a rich history of variants and alternate implementations, with XEmacs being one of more well known forks. On the Mac OS X, Aquamacs has remained a good option for a number of years. A more comprehensive list is available on the Wikipedia page for Emacs.

Both XEmacs and Aquamacs are forked from, or derivatives of GNU Emacs, which is probably the most used Emacs these days. However, other light-weight Emacs-like editors still exist, and I have been trying out three of these, vile, zile, and jmacs. On the Mac, these are available via Mac Ports, on Fink, and possibly on Homebrew.

vile is an interesting blend of Emacs and vi, and provides the modal commands from vi, but also has many of the window management features of Emacs (including similar Emacs key-bindings). It is really more of a vi variant, but the window management does make it very handy, though it does not support the text objects and other vi extensions as Vim does.

jmacs (the Joe editor’s Emacs emulation) seems to be the most feature rich, and the syntax highlighting seems to be best of the lot.

Then there is zile, yet another Emacs clone that I am beginning to love for being lightweight, and having the most Emacs-like behavior. For simple text entry, zile seems to feel to be the fastest—though in reality—all three editors start up pretty fast.

In the end, while I still end up with using Emacs/emacsclient for most of my editing (after all, I do keep a Emacs session running most of the time like the true faithful), it is still fun to dabble with these editors, if for nothing else than to marvel at the core Emacs editing experience that these micro-editors can provide, in sub-Megabyte packages (vile = 680K, zile = 251K, joe = 440K on my machine).


What’s New in Emacs 24.4

Mickey Petersen has written up an excellent round-up of the latest features
of the Emacs 24.4 release.

Read the whole article at http://www.masteringemacs.org/articles/2013/12/29/whats-new-in-emacs-24-4/.

He had also written a similar article for Emacs 24.3 (current stable version),
which can be found here.

New Settings that I am using

I have already setup the load-prefer-newer, cycle-spacing, and ns-use-srgb-colorspace options.

The new electric-pair-mode options also look interesting, and I have set these
up (I was using skeleton-pair for the auto-pairing function till now).

The new M-s . (isearch-forward-symbol-at-point) is going to be very useful. It
essentially replicates what C-s C-w does, but having a single key-stroke is a
little easier. A closely related command M-s h . (highlight-symbol-at-point)
also looks to be useful. This is especially handy with the
hi-lock-auto-select-face option.

C-x SPC (rectangle-mark-mode) finally allows replacing CUA for me.

Eshell now has even better support for visual commands; i.e., commands
which expect a terminal. See the options eshell-visual-commands,
eshell-visual-subcommands and eshell-visual-options for details.

New Interesting Modes

The new Web Browser for Emacs (eww) is great! I have already
uninstalledw3m and using eww solely right now.

The dired-hide-details-mode is also nice. It has already replaced
dired-details for me.

superword-mode looks to be useful (especially for programming Ruby, where
underscores are usually used to separate words in an identifier).

The new file notification system would be very useful, except that it does
not (yet) work in OSX (bummer).

Other Default Settings of Interest

desktop-auto-save-timeout is going to be a life-saver. The related option for
desktop-restore-frames finally does what I want.

The new electric-pair settings electric-pair-preserve-balance,
electric-pair-delete-adjacent-pairs and
electric-pair-open-newline-between-pairs do exactly what is expected.

Ruby-mode has some interesting updates, especially for indentation.


Copying the previous line to current position in Emacs

Recently, I came across a scenario where I had to quickly copy the previous line in an Emacs buffer to the current position. The usual method for doing this has been to invoke:

C-p C-a C-k C-y RET C-y

Which basically does the following:

  1. Moves to the previous line (C-p)
  2. Moves to the beginning of the previous line (C-a)
  3. Kills the line (i.e., cuts the line with C-k)
  4. Yanks the line back (i.e., restores the original line with C-y)
  5. Creates a newline (RET), and
  6. Yanks another copy of the line with the final C-y (which is what we wanted in the first place)

While this works, it is certainly not the most optimal mechanism to perform such a simple (albeit infrequent) operation.

In searching the Net, and scanning the inbuilt functions using apropos and the excellent Icicles search, I stumbled upon the:

copy-from-above-command

function, which does exactly what is needed here. This function is available in misc.el, and needs to be enabled by requiring the file to be loaded in .emacs:

(require 'misc)

Also, the there is no default key-binding for the function, and one needs to be setup:

(global-set-key (kbd "H-y") 'copy-from-above-command)

In my case, I set up the Hyper-y key-stroke for the key, which nicely mirrors the yanking keys (C-y and M-y).

This function has another nice twist, which is that it will copy the characters from the previous line only from the current column, which allows partial lines to be copied over.


Heretical Confessions of an Emacs Addict – Joy of the Vim Text Editor

Context

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 Emacs and Vim Icons

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.


Three nifty alternatives to the M-TAB key in Emacs, and a replacement.

The M-<TAB> key in Emacs provides a useful completion function (`completion-at-point’), which tries to complete the current symbol at point to something useful, usually based on other symbols in the buffer which have the current partial symbol as a prefix.

However, using this key is a pain in most OS GUI systems, since it is usually mapped to the Task Switching function as well. Note that the <Alt> key doubles as <Meta> on most keyboards.

Emacs provides two documented alternatives, <Esc>-<TAB> – which requires a trip away from the home rows to the <Esc> key, and “C-M-i”, which is far easier to type.

In fact, there is a third way of inputting an equivalent key sequence: “C-[ C-i”, which is “<Control>-[“ followed by “<Control>-i”.

This works because “<Control>-[“ (that is the left square bracket) is equivalent to the <Esc> key, and also works as a <Meta> key.

control-bracket-2010-09-29-22-06.png

The Alternative to <Meta>

In fact, “C-[“ can be used anywhere a <Meta> is required. E.g.,

M-x” can be replaced with “C-[ x

<Esc> <Esc> <Esc> (to invoke `keyboard-command-quit’) can be replaced with “C-[ C-[ C-[“.

Using “C-[“ instead of <Esc> or <Meta> has the advantage that the key sequences can be invoked from the home screen, reduces hand movement (at least on a QWERTY keyboard), and also helps avoid the finger contortions that are otherwise often needed to access the <Meta> key.

Note that sequences which involve both <Meta> and <Control> keys can also be invoked, as long as the “C-[“ is entered first. E.g.,

C-M-x” (to invoke `eval-defun’ in an Emacs lisp buffer) can be replaced with “C-[ C-x”.  Sweet.


Emacs 23.2 has been released.

Emacs 23.2 has been released.

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!


Converting from TaskPaper to Emacs Org-Mode

Why TaskPaper and Org-Mode?

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.

tasks.png

taskpapercapturewindow.png

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 (<a href="http://www.opensource.org/licenses/bsd-license.php">http://www.opensource.org/licenses/bsd-license.php</a>)
#
# Usage: From the command line, enter the command:
#
#  ./tpaper2org.rb &lt;taskpaperfilename&gt;
#
# 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 <a href="http://orgmode.org/manual/Clean-view.html">http://orgmode.org/manual/Clean-view.html</a> 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 &lt;&lt;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.


Follow

Get every new post delivered to your Inbox.

Join 81 other followers