The Changelog: Software Development, Open Source - Why we 💚 Vim (Interview)

Episode Date: July 21, 2021

On this special edition of The Changelog, we tell Vim's story from the mouths of its users. Julia Evans, Drew Neil, Suz Hinton, and Gary Bernhardt join Jerod Santo for a deep and wide-ranging discussion about "the best text editor that anyone ever wrote."

Vim, the final frontier. Sorry, that's so lame. I've just always wanted to do that. Let's run it back. Vim, a modal text editor from 1991 with roots in VI that go back to 1976. That's 45 years ago. And yet here we are in 2021, 30 years after Vim's initial release, and it's still used and loved by nerds around the world.

You can't even really call it a comeback because it's been popular for years. On this special episode of The Changelog, we thought it would be fun to hear a bit of Vim's story from the mouths of its users. So I gathered some friends, new and old, and asked them to tell me all about Vim and why they love it. Thank you to our friends at Sourcegraph for partnering with us to make this episode interruption-free. Teams with large codebases and many repos struggle with the usefulness that grep and command shift F offer. They need a better way to search and discover all their code and open source

dependencies. They need Sourcegraph. Point Sourcegraph at the repos you work with stored in any code host, then start searching. Stay in flow and find your answers quickly. Try Sourcegraph at info.sourcegraph.com slash changelog. All right, let's meet our guests, starting with Julia Evans. I'm Julia. I've been using Vim for, I think, 17 years, and I'm a programmer, and I currently, for a living, write comics about programming. Hi, I'm Drew Neal.

You may know me as the voice of Vimcast. I also wrote Practical Vim and Modern Vim. And aside from my sort of Vim work, I'm a web developer by day. And I also do sort of related to all the Vimcasts and books and so on. I do training sessions about Vim. So I've been using Vim since about 2008, something like that, I think. I'm Gary Bernhardt. The thing people are most likely to know me from is a lightning talk called Watt, which is almost 10 years old now.

Right now I'm working on Execute Program, which is an interactive learning program that's kind of unique in that we mix lots of real code examples in with explanations, all running in your browser, real code examples in the browser. I've been using Vim for about 15 years, since 2006. I was an Emacs

user before that, and then before that, you know, Visual Studio and sort of more mainstream Windows-y kinds of editors. And I also went back and forth between Emacs and Vim a number of times in the early days, so I have a lot of sort of comparison reference points there. I'm Suze Hinton. I do software development professionally and also in my spare time as a hobby. I most frequently work in Golang, Ruby, JavaScript, but I kind of like to do a little bit of everything from the top of the stack right down to almost the bare metal, not quite assembly.

And I switched to using Vim around four years ago. One thing that has always fascinated me is how people come to select their tools, techniques, programming languages, and so on. As a developer, your text editor is one of the most important choices you make because you use it all day, every day. It is the primary interface to the work that you do. I learned Vim not because I chose to, but by dictate. My programming teacher in college was a staunch Vim proponent and forced us to write all of our programs SSHed into a Linux machine

using Vim. I kind of hated him for it at the time, but I definitely appreciate it in retrospect. Shout out to John Clark if he's out there listening. I remember him once saying, Pico is a totally fine editor if you're writing emails to your grandma. If you're writing code, you better be using Vim. So that is how I came to know Vim. Here's how Drew got started. Switching jobs, I was at a job where we all used Macs. And back then, we were a Rails shop and everyone was using TextMate. And I switched to a job where it was all Linux workstations

and TextMate didn't run on Linux. So I had to pick another editor. I think the ones I was considering at the time were Emacs, Vim, and Gedit, I think. And yeah, I think it was a small company, but there were a fair few Vim users. So I thought, well, if I start using Vim, I've got a few more people I can ask questions of. So that was kind of what got me into Vim. And I knew at the time, I was aware that Vim had really good support for Rails, which is what I was mainly working with at the time, mainly thanks to Tim Pope, who created the Rails.Vim plugin way back.

So in some ways, that was sort of the gateway drug to Vim. Coming from a Rails background, I think Vim was quite popular with Rails developers at the time. So it kind of felt like a natural step. It's funny how the social, not social pressure, but just like the social environment around you helped make that decision. Yeah, yeah, that's true. I mean, I could have moved to a job where there were, I don't know, five Emacs users and two Vim users and it would have worked out

differently. We'd be all watching Emacs casts. Yeah. While Drew's experience may be somewhat common, Gary came to Vim from a completely different angle. And while I hadn't considered it before, I have to say it's a compelling reason. For me, and I don't know how common this is, but for me it was motivated by fear of RSI injury. Programming long term is dangerous for your hands. Fortunately, not the rest of you. For your hands and your wrists, totally dangerous. And I wanted to keep programming

for many more decades. So I was using Emacs, a lot of cording in Emacs, a lot of control shift, control alt, control alt shift. And Vim has basically none of that. And that for me is the most important difference

between Vim and other editors. It's input efficiency in terms of keystrokes. And a really easy way to sort of see a summary of that is in Vim, I almost never hit control. I never hit alt. If there are keystrokes that require alt, I don't even know them. And I rarely hit shift. So most of my editing is normal mode, which is the mode that Vim boots up in, and just hitting the letter keys to do things in punctuation.

And that is very different from any kind of remotely, quote-unquote, mainstream editor. Did you know that going into it? Or did someone say Vim's great for RSI? Or how did you know that? I had a bit of a scare is what caused me to take that path. And it turned out, I think, honestly, I probably just overused a muscle or something. It was sore, which is a common way to think you have RSI when you don't. So that went away. But having had that scare, I thought, if that was my RSI

coming in permanently, it would change my life, right? I mean, it's a major thing. So I decided to do something about it, and Vim is what I did. Julia has been using Vim for so long that she couldn't even remember what initially drew her in. Suze was also well aware of the editor for a while, but she only dove in somewhat recently. I've always sort of messed around with rented Linux VPSs. And when it's your own box, you tend to do all the dodgy stuff, you know, like you do all the cowgirl stuff on the server, like you modify your Nginx config live and things like that.

And usually that's done in a shell session. So really, the most practical options that you have are something like Nano or Emacs or Vim or Vi. And it's installed out of the box on so many Linux machines. And so it's just always there. And so usually I would pick it up if I needed to use it. And it was usually within that context of just like messing around in Linux without some kind of display drivers or GUI. To be honest, nothing about the experience itself made me want to pick it up. You know, I knew how to go into insert mode and get out of insert mode. And sometimes depending on the machine, you could actually get away with using

the arrow keys instead of J and K and things like that. I'd been curious and felt that it was valuable to learn properly. And I knew other developers and colleagues who used it, but I just never really felt motivated enough at the time, which is why I really only picked it up four years ago. Suze said something interesting there that I heard from others as well. She said, it's installed out of the box on so many Linux machines. It's just always there. That is definitely a strength. And it turns out it's one of the things that Suze loves the most about Vim. Because of the ubiquity, you end up in the scene from Jurassic Park where it's like,

this is Unix, I know this. And so, you know, if you have to do something really quickly on a Raspberry Pi or something, you're just like, oh, I know this. I can just do this really quickly in Vim and it's great. And so that's the dream. What I also like about it is that because it is on everything, it can be as simple or customized as you like. The biggest sort of personal virtue for me about it is that I have

a really bad short-term memory. I find it very difficult to hold a buffer in my head of like what code I need to write next. Sometimes I have to pseudocode things out just so I remember the steps of like what I'm doing if it's complex. And even just changing your mind about something and rewriting it. Getting the code out of my brain and onto the screen in front of me like as fast as possible actually really helps me not be so overloaded. And it's actually far less exhausting for me. And because Vim is designed to train your muscle memory to do very efficient, you know, shortcuts to make changes in your code, it is it is very targeted towards that as compared to kind of clicking around with a mouse or just having like maybe some a smaller amount of shortcuts it's designed in a way to just help you achieve that much faster and i'm not really one of those productivity porn people but when you pitch it in the case of just finding coding far less frustrating it's been hugely valuable for me in that i guess one of the things i love most about it is the the grammar the um slightly funky way

of doing things where like in most text editors, you select some text, usually by like clicking with the mouse or double clicking or whatever. And then having selected the text, you then run some operation on it, whether that's just deleting it or wrapping it with something or whatever. Whereas in Vim, it's kind of the other way around. You start by saying, I'm going to delete something. And then you say what you're going to delete. So it's a little bit back to front and it very much feels like a grammar. It's like, you know, you have in spoken languages, you have ways that you can assemble, you know, the verbs and the nouns and so on. And with Vim, you have these operators and these

motions. And I just love the fact that there's sort of an infinite space of combinations. I love the fact that you can install plugins that add new operators or that add new motions or new text objects. And I always feel like that's kind of like we've got our fixed grammar and it's just like we're adding vocabulary, further expanding the space of operations that can be performed. Vim is complicated. There's a lot of stuff in there, but the thing that makes VimVim is normal mode. The letter keys do things without modifiers. It's such a simple thing, but everything that is sort of special about Vim for me stems directly from that. When you first open up a file with Vim, typing on your keyboard won't insert any characters.

That's because you're in normal mode, like Gary was talking about. Normal mode is for doing non-character insertion things. Moving your cursor, copying and pasting lines, manipulating text that's already there. Normal stuff like that. If you want to insert characters, you have to switch to insert mode. This causes confusion to new Vim users because it's backwards from what's expected. It can make you feel dumb because here you are in a text editor and you can't even get the thing to edit any text. But it is one of those things that makes Vim Vim. And once you grok it,

it actually makes a lot of sense. Drew struggled with this concept like most of us do, but he came up with a great analogy for Vim's different modes that may help you make more sense of it. The point where it starts to make sense really is when you accept the modal nature of Vim. And for me, I feel like the point where it started making sense was kind of where I started to see those trips into insert mode and back out again as being, well, I draw an analogy with the way a painter works. I like to compare normal mode, which is the default mode in Vim, as being just like a painter with their paintbrush not touching the canvas. Whereas in insert mode, it's like your paintbrush is touching the canvas. And if you think of every little trip into insert mode as being like a brush stroke, then that sort of modal nature starts to really

make sense. And a couple of things that made that make sense to me was one, realizing the way the undo command works. If you make a trip into insert mode, you type some text, you pop back into normal mode. That's one little undoable chunk of work. Whereas in most text editors where you're generally in something like insert mode, you can type like one word or you can type a sentence and then you can hit the undo key. And how much text it's going to raise is a little bit of a, you don't quite know. It's like, yeah, it's fuzzy. There's, it's a to raise is a little bit of a, you don't quite know. It's like, yeah, it's fuzzy. It's a little bit like having some sort of auto save feature that says, okay, every time you've paused for more than two seconds, we're going to auto save.

It's similar sort of idea where if you've paused for a certain amount of time, maybe we'll put in a little undo stop or whatever you call it. And some text editors just don't do that at all. You just hit undo and it'll undo everything since, I don't know, you moved your cursor or something like that. And at that point where I sort of realized, okay, I'm kind of thinking about this as like little chunks of undoable changes

and it really started to feel like brushstrokes and it started to feel like the idea of being in insert mode by default just felt wrong. It's like, well, of course the painter doesn't have their paintbrush touching the canvas all the time. That's just weird. So having that sort of being able to think in modes just made everything feel natural. And from there, I mean, at that

point, you've still got a lot of Vim to learn, but at least your sort of patterns of thought are aligned with Vim's ways of making you do things. Normal mode and insert mode aren't the only modes in town. Vim's visual mode is great for selecting multiple characters, lines, or blocks of text, and then performing some operation on that selection. I love visual mode. I use it all the time. And so does Julia. Yeah, I love visual mode. One of my favorite things about visual mode is do you know how you can go into visual mode and then do like colon exclamation mark and then type a Unix command and it'll pipe the stuff you selected into that command and then replace it with the output of the command. No, I didn't know that. I think

that sounds spectacular. It's spectacular. So sometimes I'll have like a list that I want to sort. And so I'll just select it all and do like colon exclamation mark sort and then it'll sort it in my editor. I don't need to go anywhere. I was making some like shell scripts. I wanted them to have like fancy headings. So like i wrote a python script to generate the headings and then i piped that into the script in bim i don't know i don't use that so often but every time i use it i'm so happy i've never done that i mean i definitely knew about the execution of like a shell script you know from the command prompt but i know you could whatever was selected in visual mode would go into that as an argument that's pretty sweet yeah. Yeah. And that's the joy of Vim, right? Is that like all

of us use it? Like, you know, you also find that stuff you didn't know. Another joy of Vim is that it's extremely customizable and has inspired a rich plugin community. Some people really get into plugins. I install a lot of plugins. I'm not gonna lie. How many? Oh, I don't know. 40 or 50, I think. Probably more. Surely there you can whittle down and give me some of your must-haves. Like what are your favorite plugins? What should people be checking out? Well, probably on everyone's list, I think is surround.vim by Tim Pope. That feels so, it feels so vim-ish that I kind of can't believe that it's not default like core vim. It feels like that fits very nicely with the whole vim grammar and adds a very useful set of operations for deleting surrounding things, adding surrounding things, changing surrounding

things. It all feels very vimish. Another one by Tim Pope that I use a lot is Fugitive, which adds like Git functionality. And I love the way that that just gets out of your way. It's there when you need it. If I want to do a Git blame, I can pull up Git blame. I don't want to have Git blame being sort of echoed on the line that my cursor is on all the time. I find that really distracting and annoying. Yeah, I like knowing that I can get to the information in Git really easily,

and Fugitive lets me do that. There's a really tiny one that I really enjoy using. It's called Exchange. You can kind of take two pieces of code and just swap them. I find that really, really useful. It's something I really miss when I don't have it. I really like sort of adding new vocabulary to Vim's grammar. So my favorite way of doing that is by adding like custom text objects. And there's a plugin by Kana Natsuno called Vim Text Obj User.

And that's a kind of a meta plugin. It's like a framework for adding more text objects. So if you go to that, the GitHub page for that, there's a page on the wiki where he links to lots of other custom text objects that people have added. And also in the space of like adding vocabulary that fits into the grammar, I really miss having an operator for toggling comments. That's again, that's something that's not really built into Vim. I've tended to use commentary, which is again by Tim Pope, but there are others out there. I'm not sure if that's the best one to use at the moment,

but again, that lets you do sort of an operator and then specify like a paragraph or a line or a function or whatever and it will comment it or uncomment it i find that really really useful but others like to keep it a little bit more out of the box i'm actually not a huge plugin user and people do still get kind of pushy with me i made the mistake of sharing my vim rc once on on github and somebody pull requested me adding a new plugin. And I was like, that's just so out of context, really weird and very just jarring. I'm trying to think of a world equivalent of that.

It's almost like you're at a restaurant and someone just walks up and puts some food on your plate or something. Yeah, it's like, you'd like this. You should try it. I really like it. Exactly. You have the croissants here. Put this croissant on your plate. Eat it's fantastic fantastic analogy i love that such a

weird thing to do yeah and so i think people are like disappointed that you know i don't use a lot of plugins and they're trying to help so i do use some basic plugins and my plugins in my personal time vary greatly from the plugins i use for work which is actually a really interesting distinction you know at home i have some basic plugins which are nerd work, which is actually a really interesting distinction. You know, at home, I have some basic plugins, which are NerdTree, so that I have a file browser, and that's pretty ubiquitously used in the Vim community. And I have some code syntax highlighters, which, you know, you sort of take for granted

that you get them out of the box with things like sublime text and stuff like that. But, you know, if you want something specific like JSX, for example, like Vim's not going to know what JSX was. Vim was written a long time ago. Um, and so you do have to sometimes install custom things for react and view. And like,

it's a, it's definitely like a front end problem. Right. Um, and I'm assuming rust has the same thing. Um, and then what else do I have? Very small list.

Vim airline. And that's mostly just trying to give nice aesthetics to my code editor. So I'm excited to use it uh and it is it's it's pretty uh functional as well just gives you a nice looking status bar um i use git gutter and git gutter essentially it does what it says on the tin it gives you sort of get hints and things in the gutter next to your line numbers like which lines you've added which ones you've modified exactly which ones are staged, stuff like that. So I want something really, really minimal. A lot of people really love Vim Fugitive, which is this kind of kitchen sink Git plugin.

It's like never leave Vim and do all the Git things inside of it. Yeah, it's amazing. And a lot of people really love that paradigm of never leave Vim, and I get it, because if you hand it on the keyboard the whole time and you're not switching context, it is actually a really nice feeling. But it's just too heavy, and I can't justify it. I still like to have a separate terminal pane next to me via Tmux to do stuff in there and mess around. So I just use GitGutter because it's minimal and it gives me exactly the information that I want to know on the fly,

which is very, very helpful to me. And I use Control-P as my fuzzy search, which admittedly is not super performant in really large code bases, but it works perfectly fine for me personally. And then at work, I basically run ALE, which is like hooks into language engines and allows you to do things like, you know, linting within Vim and highlighting certain lines that are wrong and having explanations as to why, and like auto formatting and that kind of thing. So Vim ALE is fantastic because it supports different languages and it's particularly good with TypeScript. So Vim AL is fantastic because it supports different languages

and it's particularly good with TypeScript. So a lot of people at my job, we have like a special internal documentation page on getting Vim working with all of our stuff because VS Code is kind of like the unofficially, you know, embraced editor. And they always recommend installing AL for that reason. So I do tend to run a heavier set of plugins

at work just because there's more complexity that I deal with in my day-to-day. If Suze's non-work setup sounds minimal to you, you might describe Gary's as bare bones. I do use a few plugins, but I'm also firmly on the side of

avoiding them as much as you can, especially as a beginner. What you don't want to do is start with 50 Vim plugins, because then you're not learning Vim. You're learning this mess of plugins that doesn't match, you know, any other given Vim user. So today I use exactly eight plugins. Six of those are for language support. So very basic stuff like syntax highlighting, showing type errors and TypeScript, that kind of stuff. One of them is my color scheme, so pretty boring. And then the eighth one is like my one indulgence, which is a plugin that slightly tweaks the way that search highlighting works. But that's it.

So with the exception of language support, I'm basically using bog standard Vim with the exception of my VimRC, which adds a few things. The one plugin that I would recommend even a brand new Vim user use is some kind of fuzzy file finder. FZF is a very popular one, very widely supported. It'll be easy to get support. I use one called Selecta that I wrote myself. You can try that if you want.

I like its matching, but of course, it doesn't have all the support of something like FZF. But you do want something like that if you're coming from another editor or otherwise you will be frustrated. Gary mentioned his VimRC. If you're not familiar, that's Vim's configuration file, which people also tweak to the hilt and often share online for others to take as inspiration or sometimes copy whole cloth. My VimRC has a section titled basic editing configuration.

And if you're just starting and you want a slightly more sort of modern take on VimConfig, you could copy just that section, not my whole VimRC. You don't want the whole thing, but just the basic editing configuration. And that will change some of the defaults that are honestly old and not desirable nowadays. But it's still pretty small. It's under 100 lines, including comments. I don't actually know what setting in my fameroc does this, but I know that when I open a file, it goes to where I was the last time I was in that file. Like it jumps to my last position.

And I really love that. Even like the column in the line? I think the column, definitely the line and maybe the column. I'm not so bothered, honestly, even if it's not. But yeah, definitely at least least the line and i just love that feeling of like if i accidentally close a file and i open it i can just like undo you know even if i already closed the editor is your vim rc out there so we could link it it's it's out there yeah it's really extremely based on this thing called basic.vim which i would probably recommend using over my vim rc because mine mostly has extra garbage in it in addition to what's in there. I think basic Vim is good and my stuff just has some nonsense that I added in there. Many Vim users will lug their must-have plugins and their personalized config with them to

every machine they use. But that desire to have your Vim set up with you wherever you go extends even further. Vim mode is a thing. This is where other editors, productivity programs, and web apps mirror Vim's command mode in an attempt to make the Vim faithful feel more comfortable in a different environment. You'll find Vim mode in Sublime Text, VS Code, and even Emacs. Then there's Vimium, a Google Chrome extension, which lets you browse the web like it's Vim. And of course, web apps like Gmail, Twitter, and Trello make extensive use of Vim's H, J, K, and L navigation keys. Some people love it, others not so much, but it's definitely a phenomenon worth knowing about.

Here's Gary's take on Vim mode. I used a couple of Emacs Vim minor modes in the old times, so I learned their strengths and weaknesses. I used some kind of browser Vim thing a while back. It was, I think, before Vimium. Found it to be kind of buggy because the browser was never designed to do that. And I've tried Vim emulations in a few graphical editors, but all of those, it took me only a couple minutes to hit a number of things that were missing, you know, and that's because I know Vim proper so well. I want weird stuff, like if it doesn't have colon G or whatever, I'm going to be frustrated. Now, with that said, a good Vim emulation will get you the ergonomic benefits of Vim, which I think are the most important benefits.

You will have less risk to your hands and your wrists. And if you don't know Vim proper, then you can use an emulation and get those benefits and not be frustrated. But if you are an expert Vim user, you're probably going to miss all the things that aren't there. And when you think about what Vim is, it makes sense that the emulations are always lacking

because Vim is about 400,000 lines of C code. I checked before we started recording and it was written over three decades. And then there's all the Vim script on top of that. Like that is a lot of code. It's not just a couple dozen normal mode commands that you can implement in a little plugin and then be done. So those couple dozen normal mode commands will get you a lot of the ergonomic benefit, but it's still, it's not Vim. And the better you know Vim, the less that's going to satisfy you. I know that built into Facebook and built into Twitter, because it's built by nerds, you know, you can actually use JK to flip through tweets and like

posts. That's cool. I already know how to use voiceover on Mac, the screen reader, because, you know, I am like a big accessibility advocate. And that to me is just how you write non-broken software. You make it accessible and you test it. So to me, I think I'm much more productive in that because that's what it was sort of designed for. Whereas I think that a lot of these things are kind of this weird kind of shim and it doesn't make a lot of sense. VS Code feels really bad in Vim mode.

For me, I don't know why. I think it's just because it's just nowhere near as responsive. And so, you know, you're hitting JK and you're just like, it doesn't feel the same. It feels like someone's kind of pretending and pulling the ropes behind the scenes. So I kind of just abandoned that. And I was like, if I'm going to use VS Code,

I'm going to lead into the VS Code paradigm. I've used in that. And I think I've used it in VS Code. I've used it in Atom. I've used it in Sublime. I've used it in IntelliJ. And I found it fine. Because I don't know how to type otherwise.

It doesn't work for me. You know? So when I used those editors, almost the first thing I did was I installed the Vim mode. Yeah, like I liked it. One thing that I find really charming about Vim

is like in my email, I can do like J and K to go between my emails. Like, I can find like little tiny bits of Vim support in like lots of places and it feels like

you're in like a secret club, you know? Totally. Like in the Vim club because you just like try it out and then it works and you're like oh wow thank you fast mail so i like that's nice so that's funny because that's actually a prerequisite for me using a mail app is that kind of nav because once i think gmail did it maybe not first but the first place i felt it i was like oh i can actually just use vim navigation to navigate and then i wanted to use although i hate gmail's interface altogether but i like place I felt it, I was like, oh, I can actually just use Vim navigation to navigate. And then I wanted to use, although I hate Gmail's interface altogether, but I like that aspect of it.

I want to use a native Mac client or something. It's like the built-in mail app for Mac, can't get it done. Oh, no. Which makes sense, like Mac OS style things. And so I go shopping for these other things and like it has to have like, that's the first thing I test. Like, can I use J and K to go up and down a list? No. Okay.

You're not going to be my mail client. Cancel. So I'm with you. And I feel like, like, remember the milk supported i test like can i use j and k to go up and down a list no okay you're not gonna be my main client so i'm with you and i feel like like remember the milk supported it back in the day i mean remember the milk is still around right but like i feel like once i used it and it supported it i was like oh wow like i don't know it's kind of like an insider nerd club you're like oh you're one of us you know like whoever writes this is one of us and i like the software a little bit more because they like it. Yeah. That's cool. One place where I definitely expect to have Vim-ish key bindings is in Gmail, actually. You can use J and K to navigate up and down in your inbox. I think it's enter to open.

Even once you're looking at a message, you can press J to go to the next message or K to go to the previous message. I might have that back to front. I think X will archive a message, things like that. It's reminiscent of Vim, definitely inspired by. And yeah, I was setting up a new Gmail account the other day and hotkeys weren't turned on and I felt quite at sea without them. So that is one where I feel I depend on them. That's funny because Julia said the exact same thing and I'm in the exact same way.

Really? So we're three for three on people that like Vim style navigation. In email, I'll take it. Any website that has it, I'm always pleasantly surprised. I'm like, hey, they do this. I think Twitter even does it, although I don't really use it there. For some reason, I don't feel like a tweet has been selected. I'm just kind of scrolling.

But I think you can actually select a tweet and go JK up and down through them if you so fancy. It's always fun to find Vim in weird places. And the more you look, the more you will find Vim or things that smell like it all over the place. But why? We've talked about aspects of Vim that these four love, but I also asked them specifically why exactly they think Vim is so stinking popular. I think that once you start feeling the benefits of using Vim, it becomes very sticky for you. I mean, you said that you still juggle the two different

code editors, right? So something changed, but you still hang on to it. And I think that that actually says a lot. So I think it has that sticky factor once you start using it. The pessimistic take on this is that maybe it's some cost fallacy and you're like, well, I've invested so much in this, I don't want to let it go. I don't want to like forget all my shortcuts, right? That's a good take. Yeah.

And it's also the ubiquity as we talked about. That seems to be my favorite word for this particular recording. It's persistence as a tool on Unix machines to get work done. I like that it's just become traditionally part of the toolbox everywhere. But even in like a modern context,

so consider like you're booting up a vanilla Raspberry Pi, it's a pain in the butt to have to use like, get a keyboard and a mouse and a monitor and do all that kind of thing. And so even just flashing Raspbian on a an SD card, booting it up, you throw it on your network on a switch, you shell in and you're writing code, right. And so you can just like get started with Vim and you're just not conserving a lot of resources on things like IoT devices, because again, it's very performant. And so I think there's a lot of modern context

for using Vim, which is why it's stuck around. And it's just nice to not have to use like an entire VNC server and like get yourself a GUI in order to boot something up that is more of like a modern code editor if that makes sense and then the last thing I will say is that you have to admit it kind of still has that really cool like Hollywood hacker movie aesthetic vibes to it right like you feel cool when you're using it because there are those leet connotations around it whether or not that's fair or not fair

and so sometimes it just feels kind of nice to just use your terminal and not have anything else open, right? And you just live in the dream. So this is all very opinionated. It's not objective in any shape or form, but that's how I feel about it, you know. Vim is the best text editor that anyone ever wrote that was widely used. But I mean that in a more narrow way than it probably sounds. So every editor is going to be good at something, right? There's a reason that every editor was written. Even like Nano was written because it's small and easy to install, right? If you want to spend your whole career customizing an editor to match you exactly, you probably want Emacs. If you want really deep

language support with automated refactorings and debuggers and all that, you probably want a full on IDE. If you want a text editor that is extremely efficient at editing text and maybe not quite as good at some other things as other editors might be, then Vim is the best solution. And there's really not any kind of runner-up for editing efficiency,

unless it's something that looks a lot like Vim. That's why it's still popular. That's why it's been popular for 50 years, is because it's so efficient and anything that approaches it basically looks like Vim. Vim has a lot going for it. Ubiquity, a powerful grammar that builds on itself, it's hackable, there's a huge community around it, but it's not all rainbows and unicorns. I just had to ask these four, what frustrates them the most about Vim? What don't they like about it?

Here's Drew. One of the things I think Vim doesn't do very well is, you know, having files that have more than one language in them. Something like an HTML file with, you know, a bit of CSS and a bit of JavaScript mixed in. It's quite a common scenario these days. I mean, Vim does support it. You can have, you know, you can have JavaScript syntax highlighting for the script tags inside of an HTML file. But I think the way Vim has this idea of like file type plugins, this idea of it's very

easy to create a mapping in Vim. And if you create that mapping in a file type plugin, you can say, okay, well, this mapping will only be applied to Vim if you're editing a JavaScript file, which is really neat, but it kind of forces Vim's hand a little bit. Because when I think back to TextMate, which I don't know how many people are using TextMate today, but I know that TextMate got a lot of things right. And when I think Sublime came out and when VS Code came out,

they said, okay, well, we support TextMate grammars or TextMate themes or whatever. It's a way of having a new editor just suddenly look like it's got lots of plugins already written for it. One of the things I remember from my TextMate days is that it has this idea of scopes. I think that was the terminology used where it's very much not just looking at the current file, but looking at the cursor position within the file. And you could have some sort of a command that would run and it would do something differently

if it was in a JavaScript scope versus an HTML scope. I might be misremembering the way that feature worked, but that was kind of how I remember it. And it meant that you could have a mapping that did one thing if you were in the HTML part of a file and a different thing if you were in the JavaScript part of a file. And I think the way that Vim is so focused on file type plugins slightly just makes that awkward to do. I'm sure it's not impossible, but it doesn't feel like Vim is aligned well for files that contain more than one language. What frustrates you, Julia?

The configuration. I don't understand a lot of the stuff in my Vim config. You have end no remap. What is it? I kind of know what it means what's that mean like you're trying to i know it means you you're mapping like a um shortcut to something else like you like i might be like i have one that's like a leader in to like remove highlights if i've searched for something and it was highlighted and i want to unhighlight it right but um like i don't know what the no read map thing is about,

but I know that I see it all the time. I definitely have it in my Vim config and I definitely don't know what it means specifically. That's a little frustrating. It never really feels good when you have stuff on your computer that you use all the time where you don't know what it means. Anything else that frustrates you about it?

I think for a long time, I didn't have paste working. Like Vim didn't integrate with my system clipboard. And I found that frustrating. And then one day I figured out how to do it. And it was like life changing. And now it does. And I'm just really happy. But I'm still literally surprised every time I can do that.

Even though I've had it for years now. It didn't work long enough that you were trained in to believe it won't work. So when it does, it surprises you. Yeah. Oh, I was going to say maybe one more thing I find frustrating, actually, which is that I think the default way BIM is set up, like whenever I use BIM on not my computer, it doesn't have my config and they're just like some things about BIM's default. Like it doesn't do like indenting, you know,

like if you're editing a function on a server, which you shouldn't be, but then you are, or I am. You know. And then like I entered new line and then it goes back to the beginning of line instead of like indenting it nicely. Stuff like that. Gary?

I'm pretty good at complaining, so I'll limit myself to just one thing. Vim script. To understand Vim's relationship to its scripting language, let me contrast with Emacs. Emacs is more, is almost like an operating system that happens to ship with an editor. And long-term Emacs users will effectively end up rewriting parts of that editor sometimes, but it's still Emacs because the layers underneath are still Emacs.

So Emacs Lisp is a whole programming language. It was designed to be a programming language. Vim is not like this at all. Vim was designed to be a text editor. It had a configuration language. It was designed to be a programming language. Vim is not like this at all. Vim was designed to be a text editor. It had a configuration language. That configuration language grew over time to acquire normal programming constructs. And that is what we call VimScript. So it's a hodgepodge and it wasn't sort of designed all at once. And I don't think it's controversial to say it's kind of a mess. So that is the most frustrating part of Vim for me. And it also is one of the reasons that I avoid configuration when I can. I have a very sort of mostly stock Vim configuration

despite 15 years. And VimScript is why. Suze shared two frustrations, one social and one technical. By far the most frustrating for me is again, like it's outside the editor itself. It's the community and the culture around Vim can be very friendly. I want to qualify that first right and there's a lot of people that are

really enthusiastic and happy to help you but then there's also kind of the dark side in that i that i call it you know of the vim community which is that there can be a lot of dogma and some very bro-tastic culture you know it becomes like competitive it's like who knows the most amount of shortcuts who can customize this to be like the ultimate elite editor and, and the dogma around, you know, like even just like fuzzy finding search tools, you know, the amount of people that have like piled on me because of, because I use control P and they think that that's too slow and I should be using these other things. It's really frustrating. It's, it's like any other hobby that you see people get enthusiastic about. Sometimes they don't know how to sort of control those

emotions or to understand that people come into that hobby or that code editor with completely different motivations to them and to just maybe consider that there are those differences. So I feel like Vim doesn't do the best job at selling itself as it is. We've talked about how, you know, it has a rep for having a steep learning curve. And this just adds extra awkwardness around the tool to people getting started with it, right? Like you almost don't want to say I'm starting with Vim because you just know there's going to be a deluge of overwhelming unsolicited advice that is absolutely not helpful to people when they're getting started. And so that's one thing that disappoints me a little bit, and I definitely don't feel like being on this Vim episode is really interesting to me because I don't consider myself

part of the community, even though I've had really good interactions with people such as Tim Pope. He's fantastic. He's written some of the most prolific Vim plugins out there, and he's great. I've had a really great experience working with him. He's even pull-requested one of my Vim plugins out there and he's great. I've had a really great experience working with him. He's even pull requested one of my Vim plugins and it's awesome. But those experiences tend to be few and far between for me. But I did want to sort of give

a call out to somebody who is really great at this. When you are talking about Vim itself, when you're working with it, I still, you know, my touch typing is still not perfect, right? And so sometimes I'll just accidentally hit a key I didn't mean to. And when you're typing as fast as you are, you'll just see something very dramatic happen in Vim. You have absolutely no idea which key you hit and how to actually cancel that. Because if you don't know what you did, you don't know how to rescue it. So sometimes it can be frustrating because all of a sudden, it'll just kind of like, it'll be like a record scratch moment for you when you're in the middle of flow. And just trying to get back to where you were is annoying. I think that gets better with practice. But I think everyone's done that thing where you accidentally toggle caps lock if you haven't sort of remapped

your caps lock key, which is I'm sure why a lot of people do this. You toggle caps lock, you hit K because you're just trying to go up a line you're trying to move your cursor in the file Apple line and then all of a sudden you have this met that the whole screen goes blank and then you've accidentally hit like the jump to the man page for this specific you know thing right and usually you're just writing arbitrary code so there is no man page for the word that you your cursor is on and it starts yelling at you that I can't find it and you're just writing arbitrary code so there is no man page for the the word that your cursor is on and it starts yelling at you that it can't find it and you're just like i don't where is my code where did it go where did you take me give it back um and so there are some of those kind of jarring moments that happen sometimes um and i think that obviously they get less and less frequent

but for me i still sometimes frustrate myself in that way you can really do a lot of damage with the efficiency of the program if that makes sense for me it's still sometimes frustrate myself in that way. You can really do a lot of damage with the efficiency of the program, if that makes sense. For me, it's always accidentally getting into macro recording mode. It's like I'm trying to hit tab, and I hit Q on accident. I'm tabbing, and I hit Q a couple of times, and all of a sudden I'm recording things that I don't want to be recording. I'm like, how do I stop this? Yeah, I've recorded things for an entire half hour, I swear, sometimes.

So you hit Q again to toggle it off, and then you kind of go into a new buffer and you hit play to see what you were recording, because it's quite amusing. There are definitely times on my Twitch stream where people are like, Suze, you're recording right now, because it's just in the corner of my little status bar. But yeah, I think that tab versus Q thing

is very common too, and it's exactly the same frustration. There you have it, a few Vim frustrations. And and of course the learning curve is a big one for many folks the question is should you learn vim today maybe you gave it a try once and got stuck should you give it another go gary shared some excellent reasons why that might just be the case i absolutely would recommend it i also would recommend people not to beat themselves up over it if they decide they don't like it. Like, there's kind of this weird sort of, you know, you have to use the hard thing or you're not a real programmer or whatever.

Don't worry about any of that, but give it a try. And I can name three different reasons to do it, and I think all of them are sufficient on their own. So first, RSI. It'll prevent injury. It's a really important thing as a programmer if you want to make a career out of this. The second is speed. Vim is unambiguously faster than other editors. It's not even remotely controversial to say that. But the question, of course, is going to be whether you value speed over what you may be giving up, things like deep language support from something like Visual Studio or JetBrains IDE or whatever. So you're making a trade-off there. But for me, speed is even sufficient on its own because every time you have to stop

and like slowly make some edits is a chance for you to forget what you were doing, to lose the state in your brain. And maybe you're like eight levels deep in your stack and you're gonna start losing those levels if you have to get distracted. It's also just fun, honestly, to be fast. And then the third reason is that Vim,

unlike most other editors, is not going to go away. The Vim keystrokes in particular, so many people have them so deep in their brains that 30 years from now, you will absolutely be able to get an editor that has those keystrokes. I don't know whether it'll be Vim. I don't know whether Bram Molinar will be maintaining it, but you will be able to use those keystrokes. So any of those, for me, is sufficient, especially for the last one. If you think about the timeline, just for me, right, 15 years. At the beginning of that time, TextMate was just becoming popular. Then it

was Sublime Text was cool. Then Atom was cool. Then VS Code was cool. A lot of people switched between two of those, three of those, maybe all four of those. And that whole time, I was just getting better and better and better at Vim. And you multiply that out by the length of a career, use Vim for 40 years, you're going to be so good at it by the end and it's still going to be totally relevant, I think. As a companion to this episode, we have three YouTube videos of our guests Viming with me to give you a taste of what their Vim life looks like.

Links to those videos are in your show notes. If you've never given Vim a serious try, hopefully this episode of the changelog convinced you it's worth your while. How to go about learning Vim is another conversation in and of itself. Drew and Suze both recommended Vim Adventures, which has been described as Zelda meets text editing. I know, I know, it had you at Zelda. Unfortunately, Julia doesn't have any Vim-related zines for you, but Gary does plan to make a Vim course real soon now. We also have a channel in our Slack dedicated to Vim.

I encourage you to join the community, which is totally free, at changetall.com slash community and hop in that channel. There's lots of friendly and Vim-passionate folks in there. The channel's called Vim Party, so you know it's good. We put a lot of love into this episode, so if you enjoyed it and want to hear more like this, please let us know. Post it on Twitter, submit it to Hacker News and Reddit,

tell your programming pair it's a must-listen, write a reaction blog, whatever's your pleasure. We love hearing from you. Special thanks to Sourcegraph once again for helping us ship this interruption free, to Breakmaster Cylinder for all of the beats, to Adam Stachowiak for his storytelling and production skills, and to our very special guests

Julia Evans, Drew Neal, Seuss Hinton, and Gary Bernhardt. Y'all are awesome. If this is your first time listening, don't forget to subscribe at changelog.com and if you love our work, support us directly by joining Changelog++. That'll get you closer to the metal and make the ads disappear. Check it out at changelog plus plus that'll get you closer to the metal and make the ads disappear check it out at changelog.com slash plus plus i'm jared santo and we'll talk to

you next time Teksting av Nicolai Winther Game on