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.
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.
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 gnuplot graphing utility has always had excellent support for multiple terminal types. While the X11 terminal is a satisfactory GUI view for the graphs, I prefer to use the AquaTerm terminal on OSX as it is more ‘Mac-like’ and feels more natural.
Also, I do prefer to compile gnuplot by myself on OSX rather than downloading the pre-packaged binaries – as this gives me more control over the compilation (including getting around the stupid Apple readline bug – where Apple has essentially shipped a broken readline by using libedit to emulate the non-existent libreadline).
This local compile requires that AquaTerm be installed so that the library dependencies for aquaterm exists in:
and the corresponding headers are available at:
In addition, the AquaTerm.app itself resides in /Applications.
However, on OS X Snow Leopard, there is a catch – the version of AquaTerm is 32 bit, whereas the default compilation of gnuport results in a 64-bit version – which is not able to load the 32-bit libaquaterm dynamic libraries.
In such a case, the gnuplot compilation does succeed – however, the default terminal becomes the X11 version – which is back to square-one.
A darwinports port does exist for gnuplot – however, as mentioned in an earlier post, this port seems to depend on half of the port repository (i.e., a ton of stuff you do NOT want gets installed as well).
However, there is a easier way to get around this situation. Here’s how.
- First install the default binary for AquaTerm from SourceForge and install normally. This step is to basically setup the right folders and symlinks so that you do not have to muck with these later
- Now install AquaTerm again from Darwinports – this port has the correct patches needed – and more importantly – builds a 64 bit version by default. This will also install the application under /Applications/MacPorts/
- Now comes the fun part. We will replace two folders from the darwinports version to the previously installed AquaTerm.
- Step 1: Replace /Library/Frameworks/AquaTerm.framework with /opt/local/Library/Frameworks/AquaTerm.framework. This will ensure that the correct 64 bit AquaTerm libraries get referenced by the gnuplot compilation
- Step 2: Replace /Applications/AquaTerm.app with /Applications/MacPorts/AquaTerm.app. This will ensure that the correct 64-bit AquaTerm binary is in the correct location
- Step 3 (Optional): You can now uninstall the darwinports version by running sudo port uninstall aquaterm from a terminal window
- Download the source code for gnuplot and extract the same.
- Run ./configure (using a command line parameter to ignore the broken Apple readline) and then make and make install (install will happen in /usr/local)
That’s it! The compilation should now succeed and gnuplot will be linked with the correct 64-bit aquaterm dynamic library. Enjoy!
Hurray! The latest version of the Emacs Operating system … erm text editor has been released today. The new version is at 23.1 and has a lot of goodies packed. The three features I am looking forward to the most are:
- Native transparency
- Easy sizing of the font display via C-x C-+ and C-x C–
- Full unicode support!!
The third one is going to be most useful in the long run – with an easy ability to use the editor for texts in my native language and script. MULE was a workable option – but clunky compared to the solution in this release.
The build and install on OSX went smooth, after the usual CVS update followed by ./configure and make. Remember to use the –with-ns switch for the ./configure invocation.
I have had the need to produce charts and graphs for my work lately – and wanted to start using gnuplot. Should be easy right? After all, there is a darwinports port available, and install should have been a breeze, with just a:
sudo port install gnuplot
Or so I thought. For some unknown &!@^% reason, darwinports with its immense intelligence decided that it needed to download 75 other ports that I did not ask for, including its own version of X11, even though Apple does provide a perfectly decent implementation that I have installed.
And guess what, there is not way to uninstall these 75 at one go either. You will need to uninstall one or a few at a time using the
sudo port uninstall <junk>
command and hope that the dependency hell does not bite you … or else it is multiple rounds of fiddling with the command line and hoping that the current uninstall invocation is the last round. Argh!
The solution (to installing gnuplot, that is) was much simpler. After cleaning out the junk that darwinports installed, I proceeded to download the latest gnuplot source and the excellent Aquaterm for a OSX friendly render terminal.
After installing Aquaterm (which is a simple dmg, drag-to-Applications and you are done install), I untarred the gnuplot source, ran the following standard configure/build commands, and was running gnuplot in less than 5 minutes.
make test # This launches Aquaterm and runs some nice tests which demonstrate gnuplot’s capabilities
sudo make install
Take that, darwinports!
P.S.: The bit about using the builtin readline is necessary on my version of OSX (10.5.7) as there is some nasty interplay with the system provided readline version.