The Changelog: Software Development, Open Source - Vim round table discussion (Interview)

Episode Date: April 12, 2011

Wynn sat down with three Vim users and experts to talk about tips and tricks for using and pimping the popular text editor.

Welcome to the Changelog episode 0.5.6. I'm Adam Stachowiak. And I'm Winn Netherland. This is the Changelog. We cover what's fresh and new in open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore. You'll find some trending repos, some feature repos from the blog, as well as our audio podcasts. If you're on Twitter, follow Change Log Show.

And me, Adam Stack. And I'm Penguin, P-E-N-G-W-Y-N-N. Fun episode this week. Talked to some masters of Vim. We talked to Drew over at Vimcast, Tim Pope from hash rocket and Yehuda of Janice fame. Nice lineup. A nice lineup.

Indeed. Talking, uh, everybody's favorite cutting edge 1960s technology. Dr. Nick said, there you go. So it seems to be the,

the hot editor. I know there's some Emax lovers out there. Save your email. Uh, but them seems to be what everybody editor. I know there's some Emacs lovers out there. Save your email. But Vim seems to be what everybody that is waiting on the heralded TextMate 2.0 is waiting on. They're switching over to Vim. Oh, boy. I don't even want to talk about TextMate. That's a bad subject.

I'm a TextMate user. I know that you are too. A lot of people are switching over to Sublime, but it's not open source, so really not going to talk about it on this podcast. Yeah, that's right. But everybody's wanting to try Vim, as am I, so we figured we'd have some experts

and talk about setups and macros and kind of the history of how they got into Vim. It was really interesting, I thought. Yeah. We'll be at Red Dirt RubyConfyCoff next week. Plug that one more time before we head up to Oklahoma, Oklahoma City. April 21st, 22nd, going to be talking

Ruby, Rails, JavaScript, and doing some titanium training. So if you haven't got your ticket yet and you want to go, be sure and get it before they sell out. Fun episode this week. Should we get to it? Let's do it. All right. We're chatting today with some Vim experts on everybody's favorite command line text editor. So before we jump into Vim, let's get some introductions. So Drew, you're up first. Why don't you introduce yourself and a little bit about how you came to Vim? Hi, my name is Drew Neal. And oh God, how did it start? I used to use TextMate

and then I switched to Vim when I started working at a company where I had to use Linux. I no longer had access to a Mac. So I could have gone with G-Edit, but I chose Vim. I'd kind of been toying with it for a long time before that, but this just gave me the push. So I started using Vim full-time. And, you know, it took me a while, but eventually I started to really love it, and I wanted to start sharing with people the tricks that I was learning.

So I started the Vimcast blog and podcast. And so that's why I'm here today. We'll jump into Vimcast in just a moment. Tim? I started using Vim about a decade ago when Emacs was a little too hard for me. Since then, I've taken the right plugins. People probably know, but I've written Rails.Vim, Fugitive, Surround, several others, and maintained several dozen runtime files that ship with Vim.

And Yehuda, you are, I guess, shying away from the Vim expert label, but for those that don't know you, who are you? I'm Yehuda. I work on a bunch of open source projects, probably most notably jQuery and Rails. My day job these days is mostly working on the SproutCore framework. I, like a lot of other people, use TextMate for a while. And I'm also not a person who switched to them because I wanted to be able to access a server and use it. I was frustrated by a bunch of limitations in TextMate that i eventually stopped talking myself out of as being limitations and i saw a bunch of

people working productively in vim tried a lot many times to use it and was frequently told that i needed to like dive in go cold turkey etc and never that never worked for me because i was never willing to give up like two weeks to learn Vim. And I eventually decided that the way I would learn Vim is to pretend it was TextMate and turn on all the things that let you do that. And it was actually extremely smooth. Like within an hour, I was like approximately as productive as I was on TextMate. And as a person who hacks tools and likes to customize my environment, I quickly got into building plugins or sorry, using plugins.

And then I ended up saying like, oh, this seems like a problem. Everybody wants to have plugins. And I guess everyone uses T-Po stuff, but there's a few other things that I care about. Plus I am like doing a few different things than Tim is. So there's these plugins that I want and oh, wouldn't it be great if everyone in my office could use the same thing? So I ended up building a distribution of common plugins that I now maintain.

We're going to jump into those plugins in just a moment, but a couple episodes ago we had Dr. Nick from Engine Yard on the podcast, and he says he prefers TextMate instead of 1960s technology. So Drew, what would you say to Dr. Nick? Well, I guess he probably uses unix though doesn't he touche also how old i'm them isn't that old like i i guess what i would what is our distinction between vi and them yeah like them is it's a tool that has been around for a while

like a lot of other tools like Lisp or whatever. But that doesn't mean that when they created it, then the next year they were like, I guess we're done. No more. Obviously, it continues to be developed. So in general, I think that's a good laugh line that people say about a lot of things. But it's always a kind of weird laugh line because all it really means is that people have been working on it for a long time. It doesn't actually mean that it's out of date or anything like that. So Tim, you mentioned Emacs. So what, usually that's the equivalence and maybe it's a false equivalence that people present is, are you a Vim or Emacs guy? Then you'll kind of snicker

if you're a TextMate guy. So you mentioned Emacs. What's the difference between Emacs and Vim for you? Nowadays, it's mostly about the modal editing just once you get into that mindset it's hard to go back at the time my my difficulty approaching it was mostly just because you had to learn lisp at the same time and i always found myself editing my dot emacs file in another editor just when i get stuck and so drew what was the motivation behind Vimcast? Well, when I switched to Vim, Yuhuda's Janus plugin, or distribution rather, wasn't available. So I spent, I don't know, it was a couple of months while I was trying out plugins, discarding them, trying out something else.

Just trying to get comfortable. So, you know, for people starting out today, they can try out Janus and just have this really easy step to Vim. But at the time it was, I'd constantly be searching the web and trying to find stuff about Vim. And there's a lot of good stuff out there all over the place. But I couldn't really find any one place that gave a lot of, you know, a lot of the stuff out there all over the place, but I couldn't really find any one place that gave a lot of the answers that I was looking for. So I started Vimcast to try to be that place, basically. So that was the motivation behind it, really.

I suppose the other thing is that there are some things about learning to use a text editor that I think don't work so well as a blog post. When it comes to learning to code, you can check out someone's open source project and you can study it. You can use it as reading matter and you can see why they're doing certain things. And it doesn't matter what text editor or ide they were using um if someone designs a class in a particular way it's going to end up having those lines of code regardless of which editor they used um there's something about the the process of going from an idea to you know a piece of code it's very transient.

You don't see the actual process of editing. And so people can be extremely productive with their editors, but unless someone actually sees them doing these little tricks and tips, they could die with them, you know. The screencast format really works for showing how Vim works because there's just things which, to describe it in a blog post, it would just be really difficult to write, and it would be difficult to read. But in 15 seconds, you can show something, and people just get it.

So I know when I've picked a good topic, when I go to write up the show notes, and there's almost nothing for me to write, because it's just, you know, just watch the screencasts. I can't really describe this. Well, I highly recommend those screencasts, also the peep code video, but you mentioned blog posts a couple of times. So Yehuda, you've got one that says anyone that tried to, or I guess everyone who tried to convince me to use Vim was wrong. What do you mean by that? Yeah, I guess that was a troll title. So like I said before, I repeatedly found myself frustrated with TextMate and repeatedly was told by other people to use either Emacs or Vim. And repeatedly was told by Vim people that I need to like turn off the arrow keys and learn to like do it correctly, quote unquote. And I think that there's probably

like from a pure perspective that's probably correct i think if you're willing to do that like if you could go to a two-week training seminar where they're like all you're going to do is use vim i think that's probably right but i think like a lot of people i use my editor for my day-to-day work and i can't just be like oh I guess the next two weeks I'll get nothing done because I'll be learning my editor so um I routinely would try them and like get told by people that I was doing it wrong and like just be like forget it I don't have time right now I'm just going to go back to textmate despite the things that I found frustrating about it and I eventually was just like no I'm just to not – I'm going to pretend as text mate. I'm going to – I don't really care about productivity right now. I care about being able to write code because I have a job.

And once I did that, I realized that it was very easy. It was like – then editors are editors, right? So you have to sort of understand that there's this modal concept, but actually you could live in insert mode a lot for a while before you need to learn that there's like this other, this other mode. And it wasn't very hard. So I wrote the post mostly out of frustration. Like I am now a couple of weeks in and it wasn't hard. And why did everyone, why did it feel so hard? Everybody in the world who thinks it's hard, like this is, it actually turns out to not be hard. You know, one of the things that I love about TextMate is just the ecosystem of bundles that

are around it. And, you know, I think TextMate 2 has become the next Duke Nukem. So one of the things that appealed to me was having my editor on any platform, but I'm going to miss all those bundles. So Tim, when you set out on this Vim approach, what was the plug-in landscape and what was the first plug-in you wrote? I started fooling around with writing syntax highlighting files and simple stuff early on, but I didn't

really get into it until I found Rails. And then I went and checked, is there a plug-in for Rails? No, there's not. I came back a month later, so I was like, well, I've got to run it myself. So 5,000 lines later, we've got Rails.vim. So Yehuda, how much of Tim's plugins have made it into Janus? I think almost all of them.

Any one that I didn't put initially. I think Pathogen is the only one that, mostly because I'm being lazy isn't in there yet, but I keep... Mostly because switching to Pathogen will require some large changes to the system, but pretty much anything that anybody uses that's useful has been submitted as a patch and accepted. There's a bunch of other stuff that is more complicated, like I have a fork of Nerdtree that I hacked up to look prettier

and work more like how I wanted it to. And I guess the thing about Vim plugins is that they're sort of like Rails plugins in that Tim's work really well together because he uses all of them. But half the work of making a plugin work well inside of Janus is just like, okay, I've inserted it. It now breaks some other plugin. Can I fix that? Can I remove it? Maybe there's a configuration option. Janus to me is sort of like Rails itself in that it's just trying to make sure that everything is integrated well.

It's not so much about like there is a certain amount of like which alignment plugin is the best plugin or which tab completion plugin is the best plugin and we move on until we find the right one. But then there's also like, how do we make it work well with Nerdtree? It's like a big part of it. Or how do we make it work well with Command T? So Janice is geared primarily towards OS X and Mac then, but it does work on Linux, correct? I don't know if that's... So the answer is supposed to be yes. But Carl recently tried it on Linux and was like, this doesn't work at all.

So I think there's probably some bug that makes it not work, and that will be addressed rapidly. Carl is a person who is using Vim because he wants to use it on Linux, so making it work on Linux is a priority right now. It initially did, so something broke somewhere along the line. So Drew, where do you get ideas for Vimcast episodes? Just through using it. I'll spot myself doing something and think, ah, that's useful and it's maybe not obvious, so I should do a screencast about it.

When I started out i i was determined not to do stuff on plugins because i think there's so much that you need to learn about the the core functionality uh so the first uh gosh i'm trying to think the first time i covered a plugin was maybe episode 29 or even 30 or something um Up until then, it was all core functionality. So that's how I started out. But lately, I've started writing a book about Vim, which is going to be published by the Pragmatic Programmers. And my focus there is to focus on core Vim functionality.

So as long as I'm writing this book, all of my ideas about working with the core functionality of the editor, they're going into the book rather than into the screencast. So lately I've started sort of drawing up a list of the plugins that I find really useful and I want to show people how I use them. So yeah, I've got a big list of ideas and I just sort of pick whichever one I feel like doing at the time, usually. So I know that Tim and Yehuda are both Rubyists.

Hopefully I'm not boxing them in with that term, but how about you? Yeah, I'm a Rubyist too. Lately I've been using JavaScript more, pretty much full-time, in fact. So, yeah, but I mean, one of the reasons I chose Vim, I think Rails.Vim certainly had something to do with it. It just, it's so useful when you're working on a Rails project. Yeah, I think interestingly,

so I am also in the same position. I do a lot of Ruby. I write Ruby pretty much every day, but I spend a lot more time with JavaScript these days. And it seems like the ecosystem around Ruby, probably because of Tim, is a lot more robust. Like, there's issues, like, you delete a line in the JavaScript mode, and it, like, takes a second because there's some bug somewhere in one of the canonical JavaScript plugins. So maybe JavaScript just needs a JavaScript Tim, or maybe... But at the end of the day,

Vim is nice because it has all these plugins, but there's definitely differences in quality between things that are heavily maintained by a community of users and things that are... People like me, I use Ruby, I also use JavaScript, I want it to work with Vim, so I make it work somehow, and that's not as good.

So how much easier or more difficult is it to write a plugin for Vim as opposed to TextMate? If you're asking me, I don't know. I've never written a TextMate plugin. So I can answer that, actually. I think it is harder but

you can do more so textmate is basically is very like unixy there's like input output you just do your thing and you like shell out essentially the programs and it's your access to what is going on in the editor is very weak but that limitation i, encourages creativity. So people work around it in creative ways. Where Vim's plugins are extremely powerful. And you can even write them in Ruby if you want. And still have access to the editor context. So you can do it in TextMate, but then you're shelling out to a Ruby process and looking at environment variables. And Vim gives you a runtime that is sensible.

Awesome. looking at environment variables. And Vim gives you a runtime that is sensible and awesome. But because there's more things going on, if all you ever did was text-based plugins, you'll perhaps be a little lost. And I think the universe could use a how-to-write-a-Vim-plugin tutorial that is better than what exists right now. Maybe I just haven't seen it, and it's awesome that it exists. Are you guys Vim color I guess

customizers or do you have a preference for your favorite syntax highlighting in Vim as opposed to your regular terminal? I use my own Vivid Chalk. It's based on that

Vibrant Ink for TextMate so Janice ships with IR Black which I like a lot mainly because it I think there's a few of them

like this but IR Black does a good job of making it not look like you're in a text mode editor and I actually like

the fact that Janice makes it feel more you know more modern. But I saw there was some new theme that was posted on Hacker News that actually looked like it might be better, and I wanted to try it out and see if it's better.

Is that Solarized? Solarized. Exactly. I need to try it out for a couple days and see if it's obviously bad or obviously better. You know what impressed me about Solarize was the fact that it kind of turned the theme sideways, where usually you pick your editor or you pick your product, and then you pick from themes that were available for that, right?

Where Solarize is kind of the opposite approach. It's all these different programs bundled together in one theme. Yeah, and it seems like he spent a lot of time thinking about the theory behind it in ways that seemed sensible to me when I read his post. So Drew, Ryan Bates over at Railscast, I know his TextMate theme got popular because he used it in his screencast. So what about Vimcast? Do you have your own? I've been using the Blackboard theme,

which there's a few out there. It was the theme that I used when I used TextMate and I just got used to it. So when I switched to Vim, I looked around and I think there were a few ports out there. I picked one of them and I've been customizing it for myself. I just use it because I like it. And it looks, well, like I say, it was the one that I used in TextMate. Although lately, I mean, one of the things that people often say at conferences, when people put up code snippets in their slides, if they use a dark background, quite often it's very, very difficult to read for the people in the audience.

So I think it's really important to have a light theme, even if you don't like using a light theme from day to day, just to have a light theme even if you don't like using a light theme from day to day just to have a light theme that you you know is there and you know you can switch it on uh if you're at a conference and you're you're live demoing something or something like that so um one of the one of the light themes that i liked in text mate was called mac classic and i ported that one over to um to vim and uh in fact i've i've tended to use that one more than Blackboard, just because it was kind of, while something like that is a work in progress,

suddenly you'll find yourself working on a file with a syntax that you don't use maybe day to day, and you realize, oh, this one really needs some attention. So if you're developing a color theme, it's really good to just use it all the time so that you become aware of the gaps. You know, when I'm coding, I prefer a dark theme, it's really good to just use it all the time so that you become aware of the gaps. You know, when I'm coding, I prefer a dark theme as well. But I'm also writing a book, and when I'm writing in Markdown, large chunks of text for the book, I really prefer a white

background or a light background just because it's easier on the eyes when I'm doing non-coding work. How about you when you're writing for Prague Prog? Yeah, I use a light theme as well when I'm writing pages of text. I agree. It just feels better somehow. One of the things that the chap behind Solarized said, he said, you know, when you're outdoors reading a book, you've got white pages with black text. Generally, you don't go out and sit in direct sunlight that's that's normally too bright and too much contrast normally you'll uh you'll try and find a shady spot so that uh effectively it lowers the contrast you end up with the shadow on the page it's no longer pure white so uh one of the principles behind solarize is to lower that

contrast and make it more like yeah reading a book in the shade rather than in the bright sunlight. So in the last few days I've switched to Solarized and I've been enjoying it. I like the look of it. Look at this light yellow background, which I find quite uplifting. There's a few things that don't quite, I guess, you know, just a few gaps, but I guess they you know, just a few gaps. But I guess they'll be taken care of in time. So I think you said something that sounded right to me,

that like crystallized something that I've been thinking, which is I think it's easier to get good contrast in a dark color. So when I'm writing code, it actually is important for me to see that is a variable, that is a class, that is a method, that is a string. So I want something that enables me to have a lot of colors where on a light background,

you get much better contrast. So it's good for writing big blocks of text like when I'm writing a blog post or something, but it's much worse for writing code for me because there's only like a few colors you have to make the call the text dark right so then you're like dark red and dark blue and dark whatever right and but you can't really have a lot of different colors and so it becomes less useful so i agree and i also agree that at conferences because of the contrast issue

it is like way more important to be able to have your text be readable than to have it be like this is a string, it is a green. Any SproutCore plugins for them? Someone actually just posted to the mailing list about that. There aren't, again, to me, a higher priority than that would be making the JavaScript ones work. Like, there's massive indentation issues. There's some, like, weird performance stuff, maybe related to JSLint, but I have doubts. SproutCore itself is very... There are sorts of the same things that you could do with Rails.

I'm in a controller now, so I can do certain things. You can have snippets and all that. But there is enough pain in the Vim JavaScript experience right now that if I was going to spend time on it, I would work on that. But I think there has been enough interest in it that I think it will probably happen, like specifics for our core stuff. One of the interesting things happening

for all JavaScript development, not just in Vim at the moment, the guys at Mozilla are behind this, what's it called? JSCTags which is I think it runs on Node or it runs on V8 through Node and that allows

well, basically CTags has been around for a long time and it's got support for a lot of languages but it's always been terrible at introspecting on JavaScript code because the language is so free and there's so many ways you can define a function and add things to a namespace. And JSC Tags understands almost all of them.

I think it passes most of the tests that I've thrown at it. So yeah, I'm excited about seeing that. I think the way you should think about JavaScript is that every large framework is its own language because there is no yet class API in JavaScript. So you actually want something that knows that sc.object.extend is a class, right? You could try to introspect, like js.toolkit tries to figure it out but at the end of the day in js.toolkit you have to say like scope blah because it doesn't know that that's a class and it can only guess so much right so i the way i i would think i would want there to be a c tags for sprout core c tags for mood tools because you want something that is like has deeper you're essentially building a

language on top of it's like lisp right it's Lisp, right? It's like clause, what SproutCore, MoodTools, or whatever are. So you want something that is more than just like, I see a bunch of functions and they're keys, so probably that's a class, maybe. You want something that knows what SproutCore is. So we had Ilya Grivorek on the show recently, and he told me that we were going to be talking about Vim,

so he reminded me of his excellent site, VimGolf. So I wanted to throw it out there and see if you guys have used VimGolf and maybe what your high scores are. Yeah, I've used it. I'm not very good at it actually. I think it's an amazing site. I haven't dipped into the source code to find out how he's done it, but it just kind of strikes me as magic the way you just fire it up and it tracks all your keystrokes and reports them back to his web service. It's brilliant. It's great fun. And I've learned

a lot from seeing the way other people tackle these problems. So I actually, actually sorry proceed yeah i was just going to say just like just like you know code golf you end up doing things that you would never do ordinarily um and i think sometimes minimizing the number of keystrokes uh i don't know you have to think really hard about coming up with a good vim golf solution um uh whereas i think in general day-to-day usage you just want your fingers to act on your thought and for the thing to happen and I don't really care if it takes five keystrokes instead of three

it's more important for me that it's repeatable with the dot command for example or something like that so I've definitely got entertainment from it and I've picked up a few tricks. But I think when you look at a solution that someone uses, it's very much kind of influenced by the golfing mindset

of trying to minimize your keystrokes. It's probably not something you do in the real world. Yeah, I sort of have the same approach to coding. I have so much available RAM before I start swapping in my brain and trying to remember more than a few key combinations um that that actually is worse for me than just like doing it longhand and i often will do things longhand or like get into a pattern like i use um visual block mode a lot because i know how to do it right i know how to use it and even though i'm sure like every time i do it somebody's like oh you can actually just type in like this five keystrokes and it will do the whole thing you just did in 10. I don't have the space in my brain to remember all those things.

This is why I don't think I'm a Vim expert, actually. And I also am not very good at VimGolf, but I actually haven't looked at it in a while. And I see he added your ability to see other people's answers, which was not there in the initial release, which makes it more interesting to me in general. It's almost like a refactor my code, but as you said, some of these solutions get a bit esoteric, but I guess as long as it's your own process, it's not that bad. Sometimes less is not more when it comes to code, like in Ruby inline prox and things sometimes get a bit you know hard to read if you don't exactly know what's going on under the hood but for keystrokes I guess you're the only one consuming them yeah and I think in particular

I think it is probably the case that it's a very personal thing I think people who are like you should do you know you should use this motion. I think different people have a different tolerance for memorization and also a different amount of utility from repetition. So Vim is nice. It gives you a lot of tools. It's very much like Ruby and not Python in that way. It gives you like a million ways to do it. And I feel as long as you're productive in it, you're happy. It's good.

I guess I should ask your favorite terminal that you're running Vim in. I use ESH. But I use MacVim. I mean, not your shell, but you're using MacVim? You're not using iTerm or this built-in terminal? No, and I actually...

So again, I think this makes me a heretic, but I like hitting Apple S to save things. So I, of course, know how to do the right way, right? But I actually like, this is sort of an answer to the, like, 1960s browser thing, right? I think MacVim actually solves a bunch of things that are kind of annoying about Vim for day-to-day usage, and so I like it, and I tend to not just be like, oh, I guess I'm in the terminal. I can just type in Vim, and now I'm in Vim.

I tend to want to use MacVim. So that's actually a great point. I work with Nathan Smith, the 960 grid system guy, and so one of the things that we were talking about in moving to Vim, because a couple of guys on the team are Vim guys. And he said, you know what, then what I do with my, uh, OCD command S twice on every, every time I want to reload and save the page.

So I guess we have an answer for him. Magville. I figure there's like, I guess that there's utility in memorizing or, or knowing that or having a muscle memory of colon w but i already have like 20 years of muscle memory on apple s and i really don't see the utility of unmemorizing that and memorizing a different thing for vim specifically yeah i would second that actually exactly i um i think vim is very much set up uh it encourages you if you are creating your own mappings it encourages you not to use

modifier keys like the command key and the control key but I think there's cases where it's much better to do that, particularly the example of hitting command S twice anything where you need to do something many times

I think it's much better to create a mapping that uses a modifier key. One that springs to mind that I use actually is, you know, when you press J, it moves you down a line. And normally you would expect it to move down a display line, but Vim always moves down by a numbered line. So if you have a long paragraph that's wrapped, say it's five lines long and it's wrapped, and you press the J key, it'll move you down to the line below rather than moving you down. So I'm not describing that well. It'll move you onto the blank line below the paragraph

rather than moving you onto the line of text below the line of text. It's especially bad if you're writing paragraphs of text. Yeah, it's quite infuriating. And the Vim, it does have the option to let you move down by a display line rather than a numbered line. But you have to hit GJ. And I find that if I needed to move down five lines, basically that's ten keystrokes. It's GJ, GJ, GJ, GJ. Hammering, it's like doing a drum roll.

And I find it really easy to accidentally hit G, J, J. It's really easy to mess up, and in that case, I've got it set up, so I just hold down Command and hit J, and it does the display lines rather than the numbered lines. So that's one case where I think the Vim custom of always typing something that sounds like a word rather than doing a modifier key mapping. I think that's one case where it's much better to use a modifier key. Another one I use a lot is there's a port of the TextMate indenting and outdenting blocks of code things. So instead of doing double right angle, you do command right bracket.

I can't say this out loud at all. That's horrible. But so I, for the first like two months I used Vim, I didn't know about it. And I was just using the angle brackets and I got good at it. Like I'm reasonable, especially once I learned about period. But there, it's actually nice. Like it's annoying that when you do that, you lose what was highlighted. Often you want to do something with it.

And I just like how the Textimate one works better. And of course, you can implement it in Vim, and it is. So I use that a lot. And yeah, I feel like the wrong case for modifier keys is when you're in insert mode. In insert mode, modifier keys are just like craziness. But in move mode and visual block mode, it's good. Tim, you have a favorite set of modifier keys or tricks? I'm kind of a curmudgeon in that regard.

I've got a few. I mean, basically stuff I've learned since switching to a Mac. So like when I run my tests, I hit Command-R, but I learned colon W about 10 years ago and it's so hardwired now. Yeah. So that's, that's actually what I mean. I think like, it's good for everyone to have their, their own muscle memory. I think, I actually think it's bad for the Vim community to be like, I guess there's not really a Vim community, but it's bad for like people who are helping people learn Vim to be like, you have

command colon W, that's how you have to do it. Or like whatever the things are. I but it's bad for like people who are helping people learn vim to be like you have command colon w that's how you have to do it or like whatever the things are i think it's better for people to learn their own path because everyone's different which makes me sound like a hippie but that's not really what i mean anybody use vi mode for their terminal when they're just messing around the shell i can't stand vi mode yeah without without i mean i don't get anything i like from them i don't get a colon line i can't call an s anything i can't even tell which mode i'm in so yeah the only thing is i get confused so i learned all the emacs combos not from emacs but from bash and so i'm like pretty used to them and but i'm losing my muscle memory from them because i use them so much now where where before, TextMate is like

very Emaxy in terms of key combinations. So it's just sometimes weird context. I've actually mapped those in insert mode and command line mode in my Vim. That's my habit. I still have control B and control F, control A, control E, those I use regularly in Vim.

How would the world be different if DHH's original Rails screencast had been done in Vim. How would the world be different if DHH's original Rails screencast had been done in Vim? I think TextMate has the property of being like zero seconds to pick up like Rails actually. And I think Vim is

like, we see a lot of adoption now because Rails is maturing. So there's like, I don't think that many people actually use Vim. Let's say there's 2 million Rails developers. I don't think any noticeable percentage of those people actually use Vim. But I think among the people, like the growing up

maturing community of Rails, we're moving into more mature tools. So Yehuda is, his reputation comes from being on the core team of Rails and jQuery. And Tim, the outcry on Twitter when I put out the call for Vim guys was great with your screen name. I guess you may have a Vim tattoo or something or maybe just your plug-ins that you have reputation.

But I wanted to know, Drew, does every Brit just automatically go into voiceover and screencast work? I mean, how does your accent translate into street cred? It's been quite surprising to learn that people like my voice. I mean, just like everyone, I don't like my own voice. You know, when I hear it coming back to me, I'm like, well, do I sound like that? But, yeah, it's quite strange. People seem to like my voice, which I guess is good. And I'm just trying to make the most of that by doing more screencasts.

So I guess the reason I got into screencasting is because I love teaching. And it's a good way to reach uh to reach an audience um and I really I don't know I I really enjoy it when there's something that's difficult and which you know you invest some time getting your head around it uh communicating that to people who haven't invested that time making it easier for them to to reach that point of understanding I get a real kick out of that. So I do it because I enjoy teaching. I think that's the main reason.

And Vim is such a – it's famously difficult to pick up. And so there's a lot of meat there for me to get into. I'll put you guys on the spot real quick with a couple of closing questions. So first, any command line hacks or other tool chain tips that you'd like to share with our listeners as far as creating code? One stupid simple one that I was reminded of earlier. I don't like VI bindings in the command line, but you can bind. I think it's bound by default in Bash, and I've bound it in ZShell as well. Control-X, Control-E to open an editor to edit the current command line.

So if I'm trying to do something a little fancier when editing, and I want a real editor, I use that fairly regularly. So I actually find it somewhat surprising that Ruby-E and associated like Ruby-P are not more commonly used.

Half of why people use Perl is because of those things. And Max like dutifully copied the exact API from Perl. And so I am often like piping things to Ruby minus E, blah, blah, blah. And I think I may be the only one. Like when I found out about minus P, which is like a printing thing, I was surprised. I had never heard of it, and I asked people about it, and nobody knows about it either. So I would just say if you're going to use grep and you're like, oh, I don't really know that API, you know Ruby's regular expression syntax, so just use Ruby minus E. It's fine.

It will work great. I've got one not for the regular command line, but for Vim's command line. Lately, I've been using more and more the Ctrl-R. It opens up the next key that you press. It'll paste from the register of the key that you press. So I've been using this more and more lately. In particular, if you do Ctrl-R, slash. Slash is the register that contains your last search pattern. And I've been finding that really useful lately.

So the other one is Ctrl-R, Ctrl And I've been finding that really useful lately. So, and the other one is control R, control W will paste the word under your cursor. I just really, really been enjoying that lately. So, neat. One last question. And this is really going to put you on the spot. Who's your programming hero? So I think Max is underrated.

Or maybe not. Maybe he's rated well. So there's a bunch of things that Max had wrote and was interviewed on circa 2003. I keep meaning to put a blog post up that has a list of them. But Max, around that time, elucidated a lot of them. But Matt's around that time, like elucidated a lot of things about Ruby. And some of them are like, he says like optimizer programmer happiness

or like for humans or whatever. And I think it's like a catchphrase now, people who know Ruby now know it, but he actually enumerated exactly what it means. And I found the way he talks about it to be very useful for designing other things for like working on Rails or SproutCore, like how should you think about the problem

and I do think he's underrated I guess I'll have to go with Linus Torvalds I mean he's changed my life twice over an hour first with Linux then with GID, it's just when does he stop? I don't know if I have a hero. It's okay to say no. The reason I start asking that question is because it's just one of our field changes so fast.

And it's one of those things where baseball players and other occupations have someone to look up to, even from an early age. Computing is one of those things that sometimes you get into later in life and you really don't have that role model as you come up through the ranks. I think it's still plausible to have Kernighan and Ritchie as role models. People who were role models in the 60s are still very relevant. Indeed. Well, thanks, guys. I appreciate the time, and I know that I'm continuing on my own personal discovery with VIM as a lot of the listeners are, and so hopefully we're smarter for it.

Awesome. Thank you very much.