Comments on: Vim and the future of editors http://floatingsun.net/2009/05/06/vim-and-the-future-of-editors/?utm_source=rss&utm_medium=rss&utm_campaign=vim-and-the-future-of-editors Sun, 20 May 2012 06:51:44 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Diwaker Gupta http://floatingsun.net/2009/05/06/vim-and-the-future-of-editors/#comment-173822 Diwaker Gupta Thu, 14 May 2009 06:55:39 +0000 http://floatingsun.net/?p=1119#comment-173822 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. 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.

]]> By: tycho garen http://floatingsun.net/2009/05/06/vim-and-the-future-of-editors/#comment-173398 tycho garen Mon, 11 May 2009 20:09:01 +0000 http://floatingsun.net/?p=1119#comment-173398 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. 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.

]]> By: Nikhil http://floatingsun.net/2009/05/06/vim-and-the-future-of-editors/#comment-172780 Nikhil Thu, 07 May 2009 06:38:15 +0000 http://floatingsun.net/?p=1119#comment-172780 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? 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?

]]>