Vim and the future of editors
As is evident from the image below, something about my last post clearly struck a chord with a lot of people.
I don’t know if it was “vim” or it was “sexy”, but somehow this post landed up on Reddit. This is the closest I’ve come to being slashdotted — for that one day, Reddit drove nearly 95% of the traffic to my site. Also, before you start jumping to conclusions from the graph above, let me put some numbers out there. On average, my site gets anywhere between 200 to 400 visitors daily. On April 18th, my site got 7000+ visitors, an order of magnitude more than I normally get. That is the spike you see, and now the traffic is back to normal, thank you very much.
Since a lot of people seem to be interested in Vim hopefully, I want to discuss the space of text editors (in particular, editors for programming) and where I think we are headed.
The first observation is that both of the giants on the editing world — Vim and Emacs — are ancient by any standards. Depending o how you look at it, I think it is fair to say that neither editor has evolved significantly in terms of the underlying code, architecture and usage model in the past two decades, if not more.
The second observation is that despite the large number of editors out there, IMHO few have any significant mind and market share other than Vim and Emacs. Obviously there is Eclipse, Visual Studio, IntelliJ etc.
And so I wonder, what would the text editor landscape look 5-10 years down the line? There are many who would say if it ain’t broke, don’t fix it. However, I’m a big believer in change, and I think over time, change is inevitable. However, at this point I don’t know what, if any, substantial change is happening in the text-editor arena. No new editors with fundamentally new ways of manipulating text or amazingly compelling features are emerging. I actually don’t mind reinventions of the wheel either, as long as the reinvention delivers a much better wheel. For instance, the Vim source code is not the most modular, extensible or maintainable. And it is in C — not that there is anything wrong with it, but I think an object oriented language is better for a complex piece of software like Vim.
The only recent buzz has been about Textmate and the many clones it has since inspired. I’m really looking forward to Yzis reach a usable milestone. What are other promising editors out there that you are excited about?
Thanks for the vim pointers. I am also one of whose, who just started with vim and my appreciation is growing by the hour.
Btw. I installed the xoria256 color scheme, but it turns out my xterm supports only 16 colors. I use cygwin/X to connect to the linux machines. Do you know if I can force cygwin/xterm to display 256 colors?
TextMate is fundamentally good software, I think it does a number of things right. First it’s largely language agnostic not simply that it can read and function in any language, which almost every text editing program can do, but rather that it can be extended in any language that can be executed by the system (bash, ruby, awk, perl, python). On contemporary computers this isn’t a big deal, but it would have been crazy to try this 15 or 30 years ago when vi and emacs were new. TextMate is thus like emacs in a number of ways: it uses emacs-style keybindings, and its customizeability is one of it’s major selling point.
On some fundamental level, however, TextMate is a lot more like vim, in that it’s creator (who is awesome) said “lets provide a system that allows users to easily customize the most important 75%-85% of a text editing functionality,” Rather than, the “(gnu)emacs way” which would have been to say “lets build a system that’s totally customizeable for editing text, and… nearly anything else you might use your computer for.” This isn’t saying that TextMate fails because it isn’t as cutomizeable as emacs, but rather that emacs’ functionality includes text editing, but it also (by this point) does other things as well. In much the way that firefox, does web browsing but also does other things with the extensions.
I’m not sure, however, that TextMate (or even similar projects,) is the next thing in text editing. First, TextMate is not open source/free software. This kind of line is the start of many arguments on the internet, but I think it’s relevant for a few reasons: First, the “target audience” of a text editor are computer programers and early adopter hacker-types. This is a group of people who are quite likely to have strong feelings about software freedom, and also by the time they’ve matriculated into this target audience, to have already chosen a text editor, and given how we all feel about our text editors, not be very interested in changing.
As a historical point, TextMate, was made successful, in large part, by the success of Ruby-On-Rails. Other than the development of a new programing community, around a new product, I’m not sure if there’s anything that could catapult a text editor to success, which I think constrains the way development in this space is likely to occur.
This isn’t to say that there won’t be development. There’s a fledgling ParrotEmacs project that attempts to replace the emacs-lisp engine in gnu-emacs with an engine running in the Parrot virtual machine (developed for Perl 6), which would give emacs developers the ability to do things in any language supported by parrot. Which would be huge. Huge. Similarly there’s a project called PIDA which attempts to provide an IDE environment *around* a text editor, but not depend on that text editor, or recreate the text editing environment. It supports emacs and vim, and I think that’s huge.
Anyway, clearly, I too am quite interested in thinking about the future of this project, and I’d love to talk with you more about it, via email, as part of an inter-blog discussion, or something. I think it would be fun to have this kind of conversation.
Wow, thanks for such a detailed response! I’ll follow up with you over email, and perhaps we can do a series of posts on this subject.