Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Neovim: Creating, Curating and Customising your Ideal Editor (with TJ DeVries)
3.3k Plays9 months ago
TJ DeVries is a core contributor to Neovim and several of its most interesting sub-projects, and he joins us this week to go in depth into how Neovim got started, how it’s structured, and what a truly programmable editor has to offer programmers who want the perfect environment.
Along the way we look at what we can learn from Neovim’s successful fork of the 30-year old codebase from Vim, how it still collaborates with the original project, and what putting Lua at the heart of the system has done for casual tinkerers and hardcore plugin writers alike.
Not everyone will come away from this discussion wanting to switch editors, but I’m sure you’ll get a newfound appreciation for digging deeper into the developer tools you use everyday.
–
Neovim: https://neovim.io/
Neovim Kickstarter: https://github.com/nvim-lua/kickstart.nvim
Kickstarter walkthrough video: https://www.youtube.com/watch?v=m8C0Cq9Uv9o
A directory of Neovim plugins: https://dotfyle.com/
Vimscript’s definition of true and false: https://vimhelp.org/eval.txt.html#Boolean
TJ on Twitter: https://twitter.com/teej_dv
TJ on Twitch: https://www.twitch.tv/teej_dv
TJ on YouTube: https://www.youtube.com/@teej_dv
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Twitter: https://twitter.com/krisajenkins
–
#podcast #software #softwareengineering #dx
Recommended
Transcript
Muscle Memory in Programming
00:00:00
Speaker
While our minds are focused on programming, it's our fingers, our muscle memories, that are getting slowly marinated in the tools that we use. Think about your editor. It's there, just at the edge of your consciousness, for 40 hours a week, for years on end. It's inevitably going to seep right into your bones.
00:00:22
Speaker
I think that's why as programmers we get so attached to our editors. They don't just have pros and cons as pieces of software. They can actually feel right or wrong. And so this week I'm not going to tell you which editor to use any more than I tell you how to feel. But I am going to raise the big question. How do you make such an important tool feel good?
00:00:46
Speaker
My guest this week, TJ DeVries, I think would answer that it comes through the ability to mould and shape, to gradually personalise our tools until they fit us perfectly.
Revitalizing Vim: The Neovim Journey
00:01:00
Speaker
And the way that he does that is with Neovim. It's a fork of vim which, even if you don't use it, you have to be impressed by it. I mean, how many times in this industry have you seen a 30-year-old code base get a new lease of life? It doesn't happen.
00:01:16
Speaker
and yet they've done it successfully. I think banks, airlines, governments would give their right arm for the secret to revitalising three decade old software. So this week we're going to talk about Neovim, both as a major software project and as a personal developer experience.
00:01:36
Speaker
And as we talk through it, TJ makes a really interesting point that I think I'm going to highlight here before we get stuck in. For many of us, the editor is the first tool where you'll tweak and refine and become both the user and the developer in a perfect feedback loop.
00:01:54
Speaker
So you can see your editor as a kind of free training ground for developer centric design. It might be your first experience of being a product manager. And it starts with eating your own dog food as you are the user of the thing you want to refine. All from the humble editor that you just can't quit. Let's get stuck in and learning. I'm your host, Chris Jenkins.
Introduction to TJ DeVries
00:02:16
Speaker
This is Developer Voices. And today's voice is TJ DeVries.
00:02:33
Speaker
Joining me fresh from the text editor minds, TJ DeVries. TJ, how are you doing? I'm doing great. Happy to be here and chatting about Neovim and wherever else this conversation takes us. There's only one way to find out, right? Yeah, exactly. So I thought we'd start, of all the technical things we need to get into, I thought we'd start a bit with the personal angle, because there are so many different projects you could be devoting your time to. Why an editor?
00:03:01
Speaker
Yeah, I think part of it is I sort of stumbled into doing this as I was like a very, you know, young software developer. I was at my first like software internship and a coworker of mine used them.
00:03:16
Speaker
And i was like he was one of my favorite coworkers to work with super nice and kind and really like helpful and i just saw the cool stuff is doing so i sort of got interested in. The editor spray space more broadly you know like up until then i'd like seen a clips.
00:03:32
Speaker
That doesn't seem like my favorite thing to contribute, although some people like it, that's fine.
Neovim's Plugin Flexibility
00:03:38
Speaker
At that time, Neovim was just starting to come out and I found out about this capability that Neovim had and still has, which is the ability to write plugins in any language. All of a sudden, I was like, my mind was blown. I can write code.
00:03:56
Speaker
And then when I'm writing code, it can do stuff for me, you know, like I'm my own customer. I'm, I'm my own, you know, person. I can solve all my own problems with this. This is so cool and interesting and got me really, you know, just excited. And so I, uh, I was trying it out and I stumbled into a small problem as well that I had where I wanted to be able to center, uh, like the file name in my status line. And it wasn't like an option that you could do, right? So I was like, Oh, I don't know, whatever. And, and sort of my, you know,
00:04:26
Speaker
My naivete propelled me into sending in a pull request and all this stuff. I barely know Git. I messed up the Git history. They had to cherry pick the PR. I didn't know what was going on. Throughout it, just really nice people in the project, really willing, especially
00:04:47
Speaker
You know i'm very glad looking back at it that i was courteous and i was like valued their time and wrote a lot of tests and documentation and sort of made it a very well rounded PR not just like a.
00:05:00
Speaker
through a grenade over the wall. Here's my code, like figured out, right? And so we worked through a lot of the ideas together and I learned so much from doing that, even though I had sometimes very little idea what I was doing at the start. And that sort of got me very...
00:05:17
Speaker
intrigued in the project and really interested in that space.
TJ's Passion for Developer Tools
00:05:22
Speaker
It's a nice intersection of a lot of the things that I like doing, which I just like working on developer tools. I like being the customer of what I'm building. I think it gives me a lot of insight. It's really fun to not just solve other people's problems, really solve my own problems. I'm like, oh, it worked. It did the thing that I wanted. That's great.
00:05:42
Speaker
So that's, I think, sort of how I got started in that whole space and, you know, related to Neovim, right, with different plugins and other things like that. Yeah, yeah. It's always particularly nice when you're also a user of the thing you're building as a programmer. Yes. And you end up with so much better quality because you see the problems so much faster. Yes. Right. And you actually are very motivated to fix them because they bother you every day. Yeah. Before the public finds out, I need this sorted. Yes, exactly.
00:06:10
Speaker
So there's a lot of stuff already in there we need to unpack, and I think I'm going to pick on the first one, which was, I know when it was first announced, perhaps I should go back a step. I was a Vim user for a long time, and the thing that ejected me out of Vim was the awfulness of Vim script. I'm going to go on record saying I hate that language. And the thing I found interesting about NeoVim was this bring your own configuration, bring your own plugin language thing, which seems to have disappeared.
Extending Neovim with RPC API
00:06:41
Speaker
So it's still there and there are still some plugins that take advantage of this for sure. So Neovim has this concept of, they're called remote plugins. And instead of the Vim way that I'd kind of had it before where you compiled in the feature for a language, you would have like Vim with
00:07:02
Speaker
the Python feature or Vim with the Perl feature, right? So if you do like version in Vim, it'll print off all the features. One of the features would be like if it's compiled in with this language, right? And there's been some changes there and some improvements, although I haven't followed that too closely. But NeoVim sort of said, let's rip all of those out. And instead, what we'll do is we'll provide just an RPC and like an API that we promise will
00:07:27
Speaker
We'll keep the same, right? So you communicate back and forth with NeoVim via message pack. You send messages. NeoVim says, okay, I can handle those messages and I can do things. And so you can take any language you want and write plugins with that. And there definitely are still some plugins using that quite successfully. What's really nice about that is Lua also has full access to that same API. And so that was a really big
00:07:51
Speaker
sort of like stepping stone for Lua integration with Neovim was we already had the full API available, right? And it felt really good to be able to
00:08:01
Speaker
the same tools and tips and tricks you learn how to do it. If you're writing a Python plugin, you were able to do those same tricks inside Lua. You know, the nice thing for Lua is it doesn't require any extra installation step or any environment things or, oh, you have to have, you know, like cargo installed on your computer or the exact Python version. Right. So there is some aspect where I think
00:08:25
Speaker
A lot of people thought of said, actually, you know, Lua is good enough for the things that I'm trying to do. Right. It's definitely good enough for this and it's fast enough. And I've got any of the tooling around. It's gotten good enough that I think I can just solve the problem without reaching for something else. You know, another thing is once you start reaching for something else, you tend to start saying, oh, it's not so bad to like include the kitchen sink. Right. I'll just add a few dependencies or just add one or two. And suddenly you're like, oh, hmm.
00:08:54
Speaker
That's actually a lot bigger. It's a lot bigger than we set out to do. It's a lot more, right? And so there's some, I think, constraining feature that people enjoy about just using the built-in Lua sort of experience there. But it's still 100% supported in Neovim, and there are still plugins that use it. In fact, recently, I was showing off some of those.
00:09:17
Speaker
by writing like a random one in OCaml, which has been the language that I've been playing with. And it's like, it works just the same as all the other languages, right? Neovim doesn't care what the other language is, it's just sending messages back and forth, which is really cool. So does that mean that Lua, which is the blessed language, is that using the RPC call mechanism internally?
00:09:37
Speaker
So it uses the same shape, but we don't have to use the RPC. So we basically like during build time, we create, it's not exactly a shared library, but it's like similar concept to like a shared library that Lua can communicate with Neovim directly in process. So it's not doing any like, it's not doing any transforming it into a message, sending the message, you know, it skips all of that serialization and all those kinds of things. And it's the same, but don't write to don't write to a pipe.
00:10:07
Speaker
Right, exactly. And you get a couple things where you get some extra special things in Lua where you can like directly pass a callback, right? Because you're not serializing, so you can like have a function reference and it works just fine. You don't have to do any sort of like
00:10:24
Speaker
additional keeping track of, Oh, I sent this message later. I want to reply with this. You just like send the function over. So there's, um, you, you put it in the same spot as you would, you know, if you were sending over RPC, but you get like, you get to cheat a little bit compared to that in Lua because we don't have to serialize, right? We can just pass the Lua reference around in the C code and everybody's happy. Yeah. That makes sense. It's mostly honest. Yes. Right. Exactly.
Why Lua for Neovim
00:10:50
Speaker
Yeah.
00:10:50
Speaker
Okay, so the obvious question there, then, is, of all the languages you could have picked to bless, why Lua? It's a really good question, and people have this question a lot. You know, they kind of wonder, like, why didn't we just put, you know, V8 inside, or why didn't we put, like, Wasm, or why not, like, Python? Like, lots of people know Python. Yeah.
00:11:12
Speaker
There's a couple things. One, some of those technologies were very different when Neovim started. I don't even remember if Wasm was around. Maybe Wasm was around when Neovim started. We're talking 2016, right? They were probably both experimental projects back then. Yeah, right. Definitely not like, oh, you can build it on every platform and everyone gets why it would be a good idea.
00:11:35
Speaker
But besides all of those things, Neovim, in my mind, is one of the perfect use cases for Lua. Lua is a very simple and small language. And the features that it has are things like you can build it practically anywhere. It's just plain. I think it compiles on C89 or C99. So it's like anywhere with a C compiler, you're going to be able to compile Lua, and it's going to work.
00:12:02
Speaker
we use the lua 5.1 version which is set in stone there's no like changes right so anything that you've ever written in lua that you knew of from lua 5.1 always works forever in the oven there's no sort of like oh well that's not the way that things are anymore we added this new special keyword or something right there's no there's none of that uh there's no there's no changes there
00:12:24
Speaker
Lua's also super, super easy to embed inside of a C application, which Neovim's written in C. And so what's really powerful, right, is that we can put Lua right side by side with where we would have stored like a VimScript reference or like a VimScript, right? You're just like, oh, well,
00:12:46
Speaker
you just make a union and see, and you say, oh, either we've got, you know, this, we've got a VIM script thingy, or we've got a string, or we've got a Lua reference. If we have the Lua reference, then we use that and execute it in the Lua state. Or, you know, we do the things that we were normally doing before. And then once we're done, we tell Lua, hey, I don't, I don't need this reference anymore. And then if no one else is holding onto the reference, Lua's, you know, garbage clacks it out and all of those goodies, right? So it's really, really easy to put this sort of side by side with the C program and, and sort of like,
00:13:16
Speaker
We didn't have to throw away everything, right? We didn't have to re-architect the whole project or redo all of these other things To get Lua running and then sort of there's two probably other primary things One of them is that Lua has a pretty active, you know ecosystem in terms of the things going on in the world people are like writing Lua it happens in You know game mods or inside of like engine acts or other things, right? so there exists people who care about things like
00:13:45
Speaker
It would be really good if we had a very, very fast JSON parser.
00:13:49
Speaker
And it's like, okay, well, then we just pull that in. You know, we just, we, we can grab Louis C Jason. We can put that inside of neovim, all the Jason parsing, serialization, deserialization. Boom. It was like, I don't remember 30 X faster than what we had before. That was like inside of them. That was, you know, hand rolled for some stuff, right? So it was like, okay. So we just like boosted everything by 30 X, which matters a lot. If you're serializing lots of messages with, you know, LSP or things like that.
00:14:18
Speaker
And so that's really powerful as you get to pull in the ecosystem for some things. And then the last sort of thing is a lot of people that are using Neovim, by default, instead of having just Lua 5.1, sort of.
00:14:32
Speaker
Lua 5.1 actually the regular thing, we're actually shipping Lua JIT, which is a JIT sort of like compiler, interpreter, whatever you want to say. JITs are, I guess. Some people are very particular about the words for that, I guess, but Lua JIT is like an incredibly, incredibly fast like runtime for Lua that's ABI compatible with Lua 5.1. So you literally can't tell
00:14:57
Speaker
from embedding it in the project, which one you're using, you'd have to ask it what your version is, and it'll tell you, I'm Lou Ajit instead. And it's incredibly fast, which is nice for things you want to run on every keystroke or every time text changes. You would be like, oh, it's really nice to have that speed.
00:15:18
Speaker
uh, running over and over inside, inside your editor. So sort of all of those together, bring it to a place where it's really powerful and easy to embed. And then like as an overall summary, the language is small and that's good. I think for a scripting language inside an editor, we don't want it to be like you have to get
00:15:35
Speaker
a bachelor's degree in Neovim to start configuring. It feels that way sometimes, say, for writing a JetBrains plugin. I've written a JetBrains plugin. JetBrains are awesome IDEs, but you don't just casually stumble into writing a JetBrains plugin. Oh, something's bothering me. I'm going to just whip up
00:15:56
Speaker
this whole extra IDE experience, I'm going to write a few random Java classes, and I'm going to come out on the other side with the experience. It's not like that, right? You have this whole world of things you have to work on and understand, and the space of people using Neovim is huge, you know, all the way, oh, I'm doing hardware, I'm doing embedded, or I'm doing firmware, I'm doing software, I'm doing front-end. So you have this huge space. So you want to pick a language
00:16:23
Speaker
that is the quickest for anybody to be able to pick up in a lot of ways, right? And Lula is definitely, in my mind, that. You want to store data, you've got a table.
00:16:33
Speaker
That's it. Doesn't matter how you want to store it, you've got tables. One day structure to rule them all, right? Right, exactly right. And so Lua has this idea. It's called mechanisms over policies. And so this sort of idea that it gives you the features that you need to build something like an object-oriented system inside Lua. But it's not going to say, here's five keywords that you need to learn to make those. It's all built off of the same
00:17:00
Speaker
same idea. So you master those base mechanisms and then you can do anything you want in Lua instead of like, oh, I have to go memorize the 100 plus keywords to be able to do those things. Not that there's anything wrong with languages that do that. I like planning of languages that do that, but it is very different to sort of
00:17:18
Speaker
force people into that to just get started with configuring an editor that's one of its primary features is configurability. You're like, you need to get there somehow. And Lua is a really nice stepping stone to do that.
00:17:31
Speaker
Yeah, I think it's like targeting the habits and the needs of the audience. I found that anytime I'm configuring my editor, it's probably something that's bugging me and I fix up in a lunchtime. So something lightweight that you can just jump in and write a few lines of without thinking too much.
00:17:51
Speaker
Right. Yes. And Lua is really great at that. And it also scales reasonably well to writing larger things with some improvements people have been making in the ecosystem with something like if you're familiar with JS doc, you know, the sort of style of writing JavaScript types in a comment above the function and like,
00:18:10
Speaker
Yeah, so it's like in some ways kind of an alternative to TypeScript, but it's not in the code, right? You write some comments and then the LSP will like parse those and say, oh, I can tell that this type or these types don't actually match if you said so. Have a similar thing in Lua where you can write the types of certain functions and all this kind of stuff, right? And the tooling around that is getting really
00:18:32
Speaker
surprisingly good for Lua. And so you can still get some of this thing where it says, hey, you said you were supposed to pass three arguments, but you only passed two, right? Even though Lua like allows you to do that and all this other stuff, right? Sort of like opting in, which is nice for people writing plugins or larger things inside, but then you can kind of skip those if you're just writing a random thing for yourself to fix the problem during lunchtime. So it scales pretty nicely with some of the tooling that's coming out, which is great as well.
00:19:02
Speaker
A lot of plug-in editor things or configuration things, they're short. I often think there's not much to choose between languages below about a thousand lines. Pick the one you like the most. It's when it gets large that the different language features really project themselves out.
00:19:21
Speaker
Yeah.
Significant Plugins in Lua
00:19:22
Speaker
So maybe we should talk about how you've used Lua in anger to configure Vim, because you've written a few important plugins, right? Yeah. So I've done a few, I've written a lot of Lua and I hesitate to admit it in public.
00:19:44
Speaker
I've written a lot of VIM script, okay? I'll just put it out there. Maybe that makes the rest of this podcast. People are all done listening to my opinions. I mean, I just want to know how badly you sinned in a former life. Exactly. I've written many thousands of lines of VIM script, so not just like, oh, he wrote some config. I wrote a lot of stuff. In fact, I even wrote
00:20:07
Speaker
on our progression of getting LSP into Neovim, I wrote an LSP client in VIM script in hopes of maybe one day getting that put inside of VIM and some other things we eventually
00:20:22
Speaker
Wrote that in Lua, partially performance, partially we just wanted to be able to iterate and make it like our own design and stuff and not have to worry about trying to get those mixed together and everything. So that was one project, I guess, eventually that I wrote in a lot of in Lua. There were a couple other key contributors as well who really pushed the Neovim LSP project forward, but I've written a lot of stuff for LSP inside of Neovim.
00:20:47
Speaker
The other one that a lot of people will know if they use neovim is a project called telescope telescope is a fuzzy finder for neovim And it's built like for neovim Kind of it started off as just an experiment Between I would say trying to push the barriers of lua integration inside neovim I was much earlier in neovim's life cycle and I wanted to sort of see where are our
00:21:15
Speaker
edge cases that we're running up against where Lua support feels, oh, that's really hard to do, and it shouldn't be. I was trying to push some of those boundaries as well as explore.
00:21:27
Speaker
Can we write something that is really fast in Lua? How fast can it really be? Can it sort 100 items every keystroke? Can it do 1,000? Can it do 10,000? And sort of explore some of those boundaries. And also I was interested to see if we could provide an experience kind of like FCF, which I love and think is amazing. FCF?
00:21:50
Speaker
is a fuzzy finder that people use inside Neovim and also like from the terminal and some other places that searches. It's written and go really fast, really awesome project. I want to see, could I build a project that's like that?
00:22:04
Speaker
But it is inside Neovim in a built-in kind of fashion, in the sense that, oh, it reuses your color scheme. Can you make it so that it's all your colors? It doesn't look different because you're running it from the command line and piping it in. Does it use your colors? Can you make it so that it knows about
00:22:22
Speaker
every Neovim feature. It knows what key maps you have, the commands, auto commands, color schemes, highlights, anything. Can we make it do all of these things? It was just an experiment there. That ended up being very large and pretty successful. It's way more successful than I had imagined starting it on my Twitch stream and playing around with the idea that people were going to
00:22:44
Speaker
Really want to use it and so that's one and then maybe like the goofiest Lua project That I worked on the project isn't really written in Lua. It's written in Rust actually, but you there's a lot of Lua going on inside the project, which is a Vim 9 script to Lua transpiler so it takes in Vim
Neovim vs Vim 9 Script
00:23:04
Speaker
9 script which we can talk about a little bit if you want and turns that into Lua that can execute inside of Neovim which was also quite a fun project and
00:23:12
Speaker
Hang on, I think these back up a little bit there. So VIM 9 script is not VIM script.
00:23:17
Speaker
That's correct. So, um, VIM eight was the VIM eight dot something was the VIM version that most people have probably used. If they've been using VIM anytime in the last say 15 or 20 years, I think maybe it's not quite that long, but VIM eight has been around for a long time. I probably misspoke and someone's going to say, hasn't been that long, but it felt like that for me. It was VIM eight for as long as I can remember, basically. I think VIM forked at about or neovim forked at about
00:23:44
Speaker
seven dot four. Okay. So maybe eight is like 10 years old or something like that. And so one of the things that the community was asking for on the VIM side was we'd really like to be able to write plugins that go faster. Right. If you don't know VIM script is a literal line by line interpreted
00:24:06
Speaker
like language. So if you have a for loop and you have 10 lines inside the for loop, it will read the first line, read the 10 lines inside, go back and re-parse eval and run each line. So it's like, you know, if you have a tight loop of something, you have a lot of extra overhead that you don't need, but it's there because of the way that VIM script evolved from just X commands into a programming language. So there's lots of sort of good historical reasons for that. So, so Bram said, okay, like,
00:24:33
Speaker
Let's see what he said. Let's see what I can do to make that happen. And so he made sort of an upgraded version of VIM script called them nine script that is like. You like in some ways, it's backwards compact in the sense that like you still can do VIM script things inside of them nine script. There's no like deleting the old VIM script, right? It's like still there. But it's like there's all these new language features on top. And effectively, there's like
00:25:02
Speaker
a part of the language now that's like typed, it gets compiled into byte code, the byte code gets run, like it does all this extra stuff, right? And it's like definitely better than VIMscript, like he made a lot of decisions that are much better than original VIMscript, right? Which is not, you know, he got a chance to revisit some of those, so that's cool. But NeoVim wasn't ready, it just isn't able basically,
00:25:28
Speaker
to like port all of those changes, maintain all of those, keep all of that working inside of NeoVIM. So we were kind of at like this impasse, right? Of saying like, okay, we have this new thing that's going on in VIM, VIM 9 script. It's like an upgraded version of VIM script, right? We want to be able to still share things like the runtime files. And when I say runtime files, I mean like, oh, you load a C file.
00:25:50
Speaker
and it's going to run some code to set up VIM or NeoVim for C. We like share those as much as possible with them. We send upstream patches when we see something is missing. We pull their patches and update our code. Okay, but if they start using VIM 9 script, we like lose that, right? And that's sad. We don't want to do that.
00:26:10
Speaker
We like Vim. We love Vim. We want to work with them. We want to make sure both are the best editors they can be. How can we make that happen? So kind of did an exploratory project that turned out to actually work surprisingly well. And there's a couple files like right now. If you're using Neovim, you're using a couple of files that have been transpiled from Vim 9 script into Lua. And they're shipped by default inside of Neovim. And no one's reported any issues that I know of. So they must be working.
00:26:38
Speaker
Yeah, that's good enough for as a QA report. Yeah, exactly. So you actually sat down and wrote Rust VIN 9 script to Lua compiler.
00:26:49
Speaker
Yes. Yup. I certainly did. Yup. How did that go? So it was kind of funny because I had tried before a few times. I tried kind of a few iterations of the project where I'd written some of it in Lua before, but it ended up just getting too unwieldy. Like the project was really big. It was really...
00:27:11
Speaker
Lua is a great language, but I wouldn't want to write like a compiler in it, right? Like you don't have exhaustive matching. You don't have, you know, you like want to be able to like make a sum type and have exhausting matching on the sum types and pattern match out and like, okay, well you've fixed the wrong language then. It's like, okay, we don't need that for Lua. We just don't, there's, there's different options you can do that are better. So eventually I landed on trying it out, um, in Rust and it, it works. So like.
00:27:40
Speaker
It's just like how you do any other language, right? In the sense that like, okay, I write a Lexer, right? Okay. The Lexer is a little bit more complicated than some other languages because we have to handle some weirdness around detecting VIM 9 script versus VIM script, blah, blah, blah, stuff like this, right? And then, okay, so now we've got our Lexer. Now we just write our parser. Okay. Our parser is going to start putting these into VIM constructs, you know?
00:28:03
Speaker
I see the auto command keyword. I know what's coming next. We've got to parse auto commands, right? So we turn that stream of tokens into an auto command structure. Oh, I see that now we're in a function call. Okay, we're going to put it. So, you know, same thing you would do for any other language and then, okay, sure. So now we need to get to our like compile step basically, right? But instead of like targeting LLVM,
00:28:27
Speaker
we target writing Lua code. And so the output, instead of being like byte code, is a big string that we save to a Lua file. And there you go. So in some ways, that part's easier, right? Because you can write some Lua helper functions and do some stuff and load those in as libraries. And you can just pull those in and do
00:28:52
Speaker
runtime analysis of stuff like, oh, I actually don't know what function needs to call if this is a string versus if it's a dictionary. Okay, well, we can just check the type, you know, and we can we can do that. So there's some parts about that are way simpler than if you're trying to like
00:29:07
Speaker
Actually, I would say like basically everything about it is simpler than trying to target something like LLVM, right? You're like, it's way, it's way harder. And the other kind of fun part about it, right, is like, since you're outputting to Lua, I can just read the code and see if it looks good or not, right? Which is kind of funny as opposed to like, hmm, okay, so I see 0x07372221.
00:29:32
Speaker
Like, you know, that seems actually in some ways, you know, harder than if your output is luoco. And then the sort of side thing with that is like, I don't actually have to do the entire language in every like, possibly cursed thing you could think of to do, right? Like, our goal for the project was
00:29:54
Speaker
can we take the like normative things that get inside of VIM's repo and can we turn those into reasonable Lua? And like they're great developers, they're smart software developers, they're not just going to like let someone merge in something absolutely insane that's like abusing all of the features of VIM 9 script, right? So I can sort of like hand wave away some things and say, well, I know technically
00:30:20
Speaker
you could, I don't know, construct a function by concatenating two strings and executing and eval-ing those. Okay, cool. They're not going to do that. So I'm safe. And so there's some aspects where, at least up until now, I've been able to sort of hand wave away those problems. We don't have to worry about that. Our primary focus and the constraint that we have is we want to be able to keep
00:30:46
Speaker
sharing code between them and Neovim where we can. And like, how can we solve that? And that turned out to be at least for now and for some files, like a viable way to do that. Yeah, yeah, I can see how that's a much more tractable problem that it first seems because you're
00:31:05
Speaker
you're dealing with not the whole source language, but a sensible subset of it. You've got control over whether it suddenly goes wrong. You don't have to immediately be able to support every feature that's out there. And I often think that the dividing line between what's a compiler and what's a transpiler is, would you like to write the output language?
00:31:27
Speaker
Hmm, that's a good, it's a good definition. Yeah. Yeah. Yeah. And Lua is fun to write. So it's like, then in that sense, it would definitely be a transpiler. And the other thing that's sort of like interesting about it is for some features that are exactly the same between VIM script and VIM 9 script.
00:31:46
Speaker
I don't have to do any transpiling. I just tell Neovim, run the VIM script code, which is sort of another funny thing, right? I have already this VIM script evaluator in Neovim, right? So there's some aspects to where we got to do even easier hand waving of being like, oh, I see a syntax command. Okay. Well, those are the same.
00:32:08
Speaker
So just telling the of them to evaluate and move on. It was like, got to wipe my hands clean and move on from handling those, which was another sort of funny aspect of it. And it was a fun project. It's pretty fun to try and basically write your own language. I didn't get to control the syntax, but everything besides that, I sort of get to control some of the things. But it actually is getting used by someone. It's always been something I'd like to do is write a language. But I'm like, who's going to use my language?
00:32:36
Speaker
But this one people are using. It's shipped to at least dozens and dozens of people's computers. I've never thought of that as a selling point for writing transpilers, but it will be, won't it? Yeah, totally. So we're getting into this because on the surface that sounds like a very niche, unique situation for you to face, compiling Vim 9 scripts to a language that already supports a subset of it. But there's a much bigger issue here at play, which is
00:33:06
Speaker
weird languages and maintaining and forking. And I'm wondering, looking at Vim as a 30-year-old project and forking it in a way that works and brings some new life to the project and is successful, is there anything we can learn in general about bringing life to long-standing legacy projects?
Neovim's Goals and Success
00:33:31
Speaker
Yeah, I mean, one thing that's nice is like Vim still has a lot of life in it. So it's like it's it's good to, you know, be forking a project that is currently successful and people enjoy and use. So that's like a nice starting point and definitely not to be underestimated in a lot of Neovim success. I don't want to say anything against Vim.
00:33:52
Speaker
No, definitely. Yeah, I was more saying that's a helpful starting point if you want to have a successful project. Finding the project that people already like is a good starting place. And then I think really important to this is you really need to sort of decide what makes you different from a project either that you're forking or that you're doing. And can you sort of constrain your vision
00:34:20
Speaker
to a targetable and achievable goal and can you make sure that that goal doesn't like expand for no reason and that all the things that you're doing both like process and technical decision projects you decide to do projects you don't decide to do that they're in service of that.
00:34:37
Speaker
But then also you need to, I think, really one thing is communicate what those are so that the people who are coming to your project aren't surprised, right? When they, you know, why doesn't Neovim have X? Well, if X clearly contradicts the stated goals of Neovim, right? Of being like this hyper extensible modern editor leveraging, you know, technologies that are useful in the world around us, right? If that X doesn't make sense, then
00:35:03
Speaker
OK, then that's clear. We can just say no and we can say we're not going to do that because it doesn't it doesn't match up. And that's really powerful. And I think that vision shared both between the people working on the project, but also the people using and contributing in the community is really, really important for for the success of like an open source project.
00:35:23
Speaker
Yeah. Yeah, I can see that. But then again, I'm going to push you on this because I'm thinking of like bank projects, right? That's the classic where you've got 30 year old software. Yes. Absolutely works today for a given value of works. Yes. And you get two projects that come out of that. One of them says we're going to we're going to redo this in a way that adds in all these new features we wanted for years. And that fails because of scope creep.
00:35:51
Speaker
The other one says, oh, no, we're not going to do that. What we're going to do is, sure, we're going to rework the existing infrastructure. And that sort of gets there, but it sort of turns into a naval gazing project that never actually launches anything that's different from what's already there. How do you avoid going into those two pits? Yes, that's a really good question. So I think Neovim has been able to avoid that.
00:36:18
Speaker
I would say a huge reason is Neovim has a lot of tests, a lot of unit tests, which is good for small units of code where we can verify that the behavior that before we refactored it is the same as VIMS, which is really helpful.
00:36:33
Speaker
We have a lot of, I think, really impressive functional tests, sort of end-to-end. It's weird to call them integration tests, because it's not integrating anything. It's just Neovim. But functional tests are usually what we call them, where we can run and do stuff and control Neovim. And we can assert stuff about what the screen looks like afterwards. So you run it on an 80 by 24 screen or whatever. And then you can literally write out what the screen looks like and say, the cursor should be here. The highlight should look like this.
00:37:00
Speaker
Because he's screenshotting it, but not as an image as actual. That's just text. So they're just columns and rows with characters in them with attributes associated with them. So you can literally write this, oh, it should be in this mode. It should be showing this mode, right? All this sort of thing. And the testing for that is really, really good, really, really powerful, and a key thing that Neavim does for a lot of stuff. So particularly for the second kind of project you said, we were saying, oh, well,
00:37:29
Speaker
We actually can't rewrite this. No one can effectively rewrite it. What you're going to do is you're accidentally going to miss the reasons why a bunch of this, we'll say, cruft exists. You're like, oh, this if statement must never happen. Why would this even be here? Why is this 80 lines of code even here? And then two years later, you get the bug, you add the same if statement back in. Yeah, you find out the hard way.
00:37:53
Speaker
Right, and now it's not designed to be able to handle the if statement that way, so now it's three times as much code and you broke your perfect abstraction. Right, which is fine if you don't need to replicate any behavior, maybe, right? But if you're trying to be a proper fork, which Neovim is, right, in the sense that, like, if you open up them and you open up Neovim, you really can't tell the difference out of the box, right?
00:38:14
Speaker
But all the simple things you do in Vim will be the same as Neovim. You need some way to do that and make that easy. And there was so much work, especially done at the beginning of the project, to just build out this whole testing infrastructure, build these tests, asserting the behavior. You write the test before, you're making sure that it's going to be able to do the same thing as Vim does, except for when we're calling out that we want to change our behavior. Oh, we're going to change this default, because we think this defaults better.
00:38:42
Speaker
you know, then it's like, okay, well, then the test change and we can confirm that like the defaults change. That's good. Yeah. You know, so, so there's sort of like, there's a lot of things like that. But I think for us, for the kind of project that neovim is this sort of end to end functional test, which like if I was in charge of redoing some bank software, oh, man, the first
00:39:03
Speaker
I don't know how long would be we got to figure out what the behavior is before we try and replicate it or change it, right? Because a lot of the times it's not clear. And I think people sometimes have like a predisposition to say, well, I can just read it and I can know what the behavior is and then I can just write the better version. And it's like.
00:39:23
Speaker
Well, I'm not good enough as a developer to do that. I need to write something down to confirm what it is. And then the other problem is you kind of want to be able to keep that behavior. So even if you do it on the first try, you got it right. It'd still be good if in a year you could still count on your bank handling case X, Y, Z correctly and your money not disappearing.
00:39:45
Speaker
So I think, I don't know, that that's honestly probably one of the things that I think, you know, you can go and look in the ovens just got folder after folder of all of these tests and all these different platforms and everything, right? Because we want to make sure we're not, you know, degrading any of those things. And then after you do that, it really
00:40:03
Speaker
sets you free to write a big refactor of stuff. I don't remember, a year or a year and a half ago, I rewrote a lot of the auto commands code in the oven, which is kind of like event listeners for those people who don't know you're with. On file open hook, that kind of thing. Exactly. Yep. So I rewrote a lot of that code to let you pass Lua.
00:40:26
Speaker
like Lua refs deep into that stack. So you could just pass Lua functions directly into that sort of area, right? And as I was doing that, I just took every test that Vim had, if we hadn't poured them all yet for auto commands, and every test we had for auto commands, and I ran it every time I saved.
00:40:46
Speaker
I saved my files. And if something broke as I was changing stuff, then I realized, okay, I've broken behavior for auto commands. We need to fix this. Or if I stumbled onto behavior that I thought, hmm, it really looks like if you run three separate auto commands in a row, they run like they're right after each other. You know, so you're like, okay, so it looks like that's the case. I don't know them. And the of them have been around for a long time. Someone's probably depending on that behavior, right? Even if it's,
00:41:13
Speaker
Even if it's not documented, even if we're not making a promise about that, if I can make it so that it doesn't break that, that's really good. And so iterating on that, adding lots and lots of tests, adding lots and lots of ideas. And the nice thing for the Neovim tests, we make them run really fast. I think that's another core requirement, is if you can make them run fast, then people will run them. And if they run slow, people won't. Yes.
00:41:38
Speaker
Yeah, that's what I would do. If I'm trying to revitalize some legacy project at work or whatever, I'm going to be starting with building out this fast test suite that's going to be telling me, am I able to make the same behavior? Because that's really important. Yeah, because the danger is with big rewrite is that you think you know what you're getting into. Whereas writing down a lot of tests says you know precisely what you're aiming for.
00:42:03
Speaker
Yeah, I don't know if you've ever experienced this where you see a chunk of code, and then you're like, oh, it's so ugly. Well, first off, I usually wrote it, right? So you're like, oh, it's so ugly. But besides that case, you look at it and think, oh, it's so ugly. I can definitely rewrite this and make it better. I'm smarter now, or we know more now. And then you spend a few days hacking or whatever on it. You're writing it. And then you get done, and it's the same exact code that you had before.
00:42:33
Speaker
Yeah, that kind of happens. And so, you know, rewrites tend to suffer from this problem. There's so many places along the way, whether it's forgetting some behavior or not solving the original problems or adding some new behavior or some adding pathologically bad case that you didn't know and yours ends up slow. There's like all these things that without measuring and without actually, you know,
00:42:57
Speaker
like putting the science in computer science i guess you know you could say like you're you're just sort of going off of your gut and like sometimes that works good i mean some people are really good at this and they're just able to sit down like i don't have this uh i don't have that gift that's okay you know i like to write the tests i like to make sure i'm doing what i want and then and then i can iterate on it just like i would iterate on you know any other projects and i find
00:43:18
Speaker
fast iteration tends to beat full rewrites. That's been my experience at Neovan, is that we're able to iterate really quickly on a lot of these features with confidence because we have good test. I don't like saying test coverage because it makes it sound like we're counting lines. We're not doing line, but test coverage in the feature sense. It makes you feel really confident that, yep,
00:43:42
Speaker
I got green on CI. I didn't mess anything up. Sweet. Let's merge it and we'll keep moving. And that's really, really powerful to push a project forward and allow people to explore and try new ideas. Even if you scrap a PR and you're like, that wasn't the right way. I've had a few PRs where I've scrapped them for Neovim or whatever. It's still like, oh, I was able to find out it was a bad idea instead of living with the regret of never shipping that feature. It was actually a bad feature. I was wrong. That's OK. Moving on.
00:44:12
Speaker
Yeah. This raises the question then, of all the obvious possible choices, what's the test suite written in that works so far? Oh, it's Lua. Yeah. It's Lua, I was wondering. Yeah. That was actually one of the ways that Lua started. Because even before Lua was properly the scripting language, we had a lot of tooling and some other things built around Neovim that was using Lua. And the nice thing is you can really easily hook into the FFI and all this other stuff.
00:44:41
Speaker
load out constants from them, or you can call functions, or you can do stuff at that ABI level in that C level that is very difficult sometimes to do otherwise, or requires a lot of maintenance. Oh, we've got 10,000 constants over here. We need to make sure they're all the same between these two languages. Oof.
00:45:02
Speaker
Painful, right? And we even, I don't actually know exactly when this started. I'd have to go check some of the history because I wasn't involved with this part. But we were even doing some simple things where we would generate some C code from Lua so that we could have some introspection into something like generating docs based on a Lua table. And then you would generate some very simple C file with
00:45:28
Speaker
with those things as comments, right? But then you get those, you can like put those into the documentation. You can like save those off somewhere, do other things like that. So it's like Lua was kind of used in some of the build and testing stuff before it was even sort of like the official scripting language of Neovim, which is really powerful.
Testing and Integration with Lua
00:45:45
Speaker
Right. So if I want to do this at the bank, I need a lightweight scripting language that's really fast, that has good FFI with COBOL.
00:45:54
Speaker
Yeah, which would probably be Lua, because I'm sure COBOL has like good FFI with C and so then you're already done basically. You know, you just like, you just can't pretend probably in the middle or something like that. Bro, he wants to talk about Neovim, but you're also proving to be an ambassador for Lua too.
00:46:09
Speaker
Yeah, I am. I am a huge fan of Lua. I think it's a really elegant and beautiful language that composes lots of little small things together and makes you able to build big things, which I think is just super cool. So yes, huge fan.
00:46:26
Speaker
I'm going to ask you, this is a bit of a wildcard, but one of the things, so I used Vim, the original one, for like 10 years, got disillusioned by Vim script and switched to using Emacs.
00:46:42
Speaker
in Vim mode because it has a really good Vim emulator. One thing I think Emacs does really well as an editor that you want to tweak is you can do kind of interactive writing of codes. You can write some code and evaluate it and it's already running in the editor. What's the support for writing Lua in Neovim to change Neovim as you're writing it?
00:47:05
Speaker
Yeah, it's actually, I think, really good. So Lua has this concept of sort of like packages or modules. They're just files basically, right? And like files are just a big chunk of Lua code. They're like calling a function, right? And so you can actually just tell Lua, hey, reload this file.
00:47:25
Speaker
And it will just do it in the current execution state, right? Or you can just re-execute the current file that you're in, if that's all you're doing, right? But if you want to sort of update all the references, you would need to tell Lua, please reload the file properly, right? And you can do that interactively. And that's how I develop most of my Neovim plugins that I write is I just reload it live as I'm going. I resource either the file or tell it to reload five files or something like that.
00:47:55
Speaker
I mean, and it'll just it'll just do that. And besides for a few sort of like edge cases, I mean, if you want to test, like, does it work when the oven starts up? You kind of got to like, you know, you kind of got to go do you got to go restart it, right? Yeah. I mean, it's nice because usually like many of them starts in like 50 milliseconds or something. So it's not like it's a super pain to close and close and run it again. But
00:48:18
Speaker
But I think that the support for that in Lua is really good. It's very interactive. There's no sort of like state that you can't reset, especially if you're sort of setting up your your plugins or your your things to be done like this. You know, maybe if you're doing like a million globals and you're like doing this complicated web of like references, you'll have a really hard time solving that. But if it's sort of like, I just want to reload, easy peasy.
00:48:44
Speaker
No problem at all. Really easy to do in Lua. Cool. Then, I mean, because you're coming across as a power editor user, obviously. You've fallen down that rabbit hole. Yes. I'm just thinking...
Personalizing Neovim
00:48:56
Speaker
If we're talking about customizing your editor, we should probably talk about why you'd want to. If someone's there using, I don't want to pick on a particular editor, but the editors that you wouldn't do any more than set preferences on, what are they missing out that you as a power editor hacker feel you have? So this is like a common question I get, you know, like I stream on Twitch and I'm doing other stuff like that. And so people are like, convince me why I should use Neovim. You know what I mean? And so my answer always is no.
00:49:29
Speaker
That's not my point. That's not what I'm trying to do. One of the ideas that I've been working on and trying to think about is, why do I like NeoVib? Obviously, I like it, but why? Other people like it too. It's one thing for just me to like it, but lots of other people seem to like it.
00:49:52
Speaker
And the concept that I have coined, I guess, with this is the idea of instead of an integrated development environment, like an IDE, we have this personalized development environment, a PDE. And there's a few, I would say, characteristics that define whether something is IDE versus PDE. And one of them would be that the average user
00:50:16
Speaker
configures the editor by writing a programming language, right? So, they have to like write code to configure the editor, right? And that's sort of like, in a sense, sort of the key defining characteristic of what makes a PDE.
00:50:33
Speaker
And the average user is an important part because there's tons of people writing plugins for VS Code and JetBrains. But the average user doesn't even know that that's like possible. They just know that there's like a storefront and I don't know, they probably think like they're just from Microsoft or something, right? You know what I mean? Which is totally fine.
00:50:54
Speaker
My thought with this is that there are certain personalities, effectively, that are interested or attracted to this idea. It's orthogonal to whether they're a good developer or not. It's just completely orthogonal to this. I think curiosity, in general, probably correlates with how effective of a software developer you are, but it does not have to be curiosity in the realm of your text editor.
00:51:20
Speaker
You can be super curious about network protocols, or like, how does the browser repaint things, or like, what's the best way to make this thing look good with CSS? And you're like, really... There's no social things to be interested in, right? Exactly, right? So, I think curiosity probably correlates with effectiveness, but I don't think curiosity
00:51:44
Speaker
of your text editor, right? That's like an additional add on that comes in. But a lot of people, I think, do enjoy this idea of being curious and interested and tinkering with the tools that they're using every day. And then in addition to that, I generally find that people really like, and this is for me as well, they really like removing those small annoyances that like are only possible
00:52:09
Speaker
when you can make it yours. There's no possible way for me, the maintainer of Neovim, to predict every way people are gonna wanna use Neovim. I'm constantly surprised. I'm constantly surprised how I use Neovim. I'm like, I didn't think I was gonna do that, and then I do it, right? So if I can't predict my own thing, I definitely can't predict everybody else's. But if I can make a system that allows people to customize and personalize to themselves, then they can find the way
00:52:38
Speaker
to make that their own, right? And I think that doesn't appeal to everybody. Some people are like, oh, the reason I code is because I want to ship this product. Then you're probably like really bored with thinking about your editor and you don't even really care, right? Or, oh, the reason I write code is because I really like, you know,
00:52:56
Speaker
whatever it is, collaborating with other people and solving big problems. Then you also probably are like, can I get this editor out of my way? I want to do the other thing, right? But some things, they just probably, irrationally, probably too much, they just bother me. I had to click three times and I'm like, ugh.
00:53:14
Speaker
Oh my goodness, my day's ruined. I have three clicks today. I can't believe I have to do that every time I want to submit something. And so I'm like, well, why not just write a function for that? Why can't I just do that? And then that's what Neovim lets me do. So that's that idea of the personalized aspect plus code. I think it really
00:53:33
Speaker
appeals to some people, and I think a lot of people much smarter and better at this than I am in the Neovan project have helped maintain that ability to have a system that follows this sort of Lua idea of mechanisms over policies. In a sense, we give you the tools that you need to construct the stuff that you want to do. We're not going to prescribe. These are the 50,000 different keywords you need to know or special classes you need to know or whatever it is.
00:54:00
Speaker
You don't have to do those things. You can just like write Lewis. So that's sort of that's at least my current hypothesis or theory about what's going on, why I enjoy and why other people do. And also why for some people it just looks like the biggest and lamest waste of time you could imagine. Right. Which I totally I totally get. Although I will say I do think I've become a much better developer
00:54:26
Speaker
by using Neovim, not because I use Neovim, but because I've been able to be my own customer and I've been able to iterate on that.
00:54:36
Speaker
The feedback loop for me being my own customer and making my own thing is as fast as I could write the code. The feedback loop for me iterating on a design and getting it shipped to customers at like a day job, at my first place that I worked was a large medical health records company. My feedback loop for that was like a year and a half.
00:54:57
Speaker
That's when I'd find out what customers thought about the feature I made, right? Well, it's like, okay, it's really hard to iterate on API design, on taste, on, you know, performance, on style, on all these things, right? When I don't hear anything back for a year and a half. And then if I pick something, I don't hear anything back for six months, right? As opposed to like, I'm doing something in Neovim.
00:55:19
Speaker
I didn't like it. Okay, let's fix it." And then it's like, boop, boop, boop, boop, boop, boop, boop, boop, boop. And so you get to try a lot of things. And so I think it is possible to take some of the struggles that people normally sort of associate with wasting all of your time inside of Neovan and turn those into sort of like effective learning opportunities for debugging or reading code or collaborating or contributing to other projects, right? All these sorts of things.
00:55:48
Speaker
I can do those inside Neovim and Neovim is sometimes just like a vehicle for doing those things. And I think it's an ineffective one. So it is kind of fun. I think people sometimes look past that, but I wouldn't do any of them if I didn't think it was fun. So I get why they think it's stupid. You know, like I get both sides. I'm with them. You know, I get it.
00:56:05
Speaker
Yeah. There's also the aspect there of like when making it possible, right? You couldn't, if you're working at a healthcare provider where the feedback loop is a year and a half, you can't suddenly decide you want to customize the software, right? And it's the same with editors. If you make the bar to just tweaking this little thing very, very low and very, very easy, you might find that your users actually are those personality types and they didn't know.
00:56:33
Speaker
Yes. I think there's probably some doctors that wish they had the neovim of healthcare records. You know what I mean? They probably wish that they had that instead of getting a top-down mandate for some of those things or whatever. That's definitely also one of the aspects of a PDE that I think
00:56:56
Speaker
The important that is your configuration is the code it's the same code that used to write plug-ins and do larger larger modifications later writes like i write to configure. Something small then i do a little bit more lewis and i have something big and then eventually i just like accidentally wrote a plug-in and like oh.
00:57:14
Speaker
I could like share this with somebody and it like might be useful to them. Right. And so there's this really cool aspect, I think, as opposed to the way you configure like the code is usually through like the settings bar or some JSON file. That's not how you write functionality. Right. So there's a disconnect from there's not a good on ramp from zero to plug in as opposed to like for a PDE.
00:57:38
Speaker
which I made up so I get to choose how, it's fine. There's that on-ramp is like, it's there, right? So you have the same on-ramp all the way along and those, that language and the way you do it is all the same. Yeah. Yeah. There's not this sudden wall where you switch from the configuration language to the programming language. Yeah. I'm not sure I'm prepared to let that barrier disappear in my next banking project.
Kickstart Neovim and User Experience
00:58:03
Speaker
Yes, for banking, we probably want to configure it. The wall's really good, yes. Okay, so if somebody wanted to take the plunge and see if maybe they got the tweaking the editor bug, I know you have a good place to start, so tell me about this.
00:58:22
Speaker
Yeah, so there's a project that was sort of started and kicked off initially by some other people in the community. But over the last year or two, I've sort of taken on more of a role in called Kickstart and VIM. And the goal of that project is very different from, say, a NeoVIM distribution. Not that there's anything wrong with those, but different constraints, just like we had talked about before. And the goal of Kickstart is like, OK,
00:58:52
Speaker
It's pretty daunting to go from the editor that you see when you open up Neovan with no configuration, right, to something that you feel like, oh, I could see myself being productive in this, right? That's a big, there's a big gap there. You kind of have to make a few choices up from which can seem too much. Yeah.
00:59:12
Speaker
Yeah. And, you know, if you get unlucky and you stumble onto an article from a year and a half ago and you didn't recognize it, then you're going to like set it up in some way and then hear someone else talking about it and everyone's doing something different now or whatever. And you're like, oh, my old thing's ruined, even though.
00:59:27
Speaker
You've probably still gained a lot of valuable information and round two should be easier, but regardless of that, right? So the idea is kind of like Kickstarter is this project that primarily is just this one file. We have a few other files in the project to sort of show next steps, how you could do other things, but they're ancillary. They don't actually matter. You don't need those. You could just literally copy the Anitlua file and paste it into the right spot on your computer and it will work just fine. So is this one file?
00:59:57
Speaker
And it, the goal of that file is to start from zero and tell you either a few places you need to go read. Like if you've never opened them or any of them before, you need to go do VIM tutor so that you can like learn that the arrow keys aren't the best way to move around and how to exit the editor.
01:00:14
Speaker
Right. You're like, okay. So like those two things you kind of like need to, you need to get right. And like a few tips of where you can learn about Lua. But, but after that, it shows you all the basics from setting options. Like how do I set options? How do I change basic configurations? How do I start doing key maps? How do I start doing auto commands? Right. How do I make that? So it's like key maps are like, how do I make the do that introduce something when I do something? Right. Then auto commands, like how do I make the editor do something when it does something?
01:00:44
Speaker
Oh, that's a nice way to look at it. Right. Right. And so you're like expanding the scope of how you can do it. And then after we've done those and you're sort of introduced to those, we introduce a package manager for NeoVim called Lazy. And it is just like an easy way to get projects from GitHub, put them in the right spot, get them updated or anywhere you can download now just from GitHub to and like get those installed and set up. And we show you the different ways that you can get those projects installed.
01:01:10
Speaker
we install some of them and then we show you moving from zero configuration for plugins to some of the more advanced ones, the sort of skeleton of how you would set them up, right? And the project is about
01:01:23
Speaker
Last time I checked when I was finished, it might be just over. It was 299 lines of code and about 400 lines of comments. And that's all the setup. So I wrote a lot of docs. I tried to explain like literally every line, right? So you can start at the top of the file, you read down to the bottom. And when you're finished, you're like, oh, okay. So this isn't as overwhelming as I thought, right? And
01:01:47
Speaker
when you're done, you have, you know, an LSP so you can do auto completion and go to deaf and go to references and you see all the key maps that set that up. So you're not like lost. You're not like, okay, but how do I do anything? It's like, okay, well you do it by pressing the buttons that you read as you were going through, right?
01:02:04
Speaker
It has a fuzzy finder for telescope, right? So you can search through files or you can search through your workspace or you can grep for stuff. It has tree sitter set up, which initially is just for like doing highlighting and some indenting and things like that. And it has auto complete set up. And then it has a few other things, you know, color scheme and a few other sort of small, small aspects going on. And so it's like when you're done, you have effectively this mini like editing environment that you should be able to understand
01:02:33
Speaker
I'll say all of it, right? All the important bits you understand after reading through the file. And you're like, oh, I can compose this with other things I know. Oh, I want to switch the color scheme. Easy. I go to the part where I read about color scheme. I switch which one. All done. Oh, I want to change the key maps because I don't like pressing G before I GD for go to definition. I don't like G. I want to press Control-Enter or something. OK, well, I just go to the spot.
01:03:02
Speaker
I changed the spot where it said GD and now it says control enter. Boom, I understand it and I know everything. The idea is that it kickstarts this journey because it is definitely a lot to start with. We've been trying to think how can we solve this problem in the open in general because what we don't want to do is sacrifice the extensibility.
01:03:24
Speaker
You don't want to say, oh, we're going to close off the extensibility and the abilities to make it personalized. But that doesn't mean that we can't do anything to make it simpler to start, right? And like kickstart is an attempt that I've been sort of doing for a while and ongoing to help make that first step of your journey, right? Like giving you a kickstart on the journey. It's not supposed to be the end goal. I'm not saying I told you everything that you need to know. I'm hoping that I'm giving you the tools to start being able to do that.
01:03:50
Speaker
And then I recently released a video about sort of me walking through that and sort of explaining it out loud. Some people I think prefer hearing, especially at the beginning, you know, some thoughts about it as opposed to reading it. So those are sort of like goals of how we can do that on ramp. Right. And like in
01:04:09
Speaker
in the way that I structured the project itself is in on-ramp, right? In the sense that we start with, here's the things you know outside of NeoVim, you need to know these, then you need to know about this about NeoVim, and then here's the simplest thing you can do, a little more advanced, a little more advanced.
01:04:24
Speaker
plugins, simple plugins, more advanced plugins, big plugins, right? And so it's sort of that same on ramp. So ideally you're not sort of like bombarded with 80 concepts at once. You can do them one at a time. Yeah. Yeah. Yeah. And I do think there's, um, like there's a difference in between tools that cater for beginners or occasional users and tools that cater for people that are going to use this 40 hours a week for the next 10 years. Yes. But that doesn't mean that it has to be a binary choice between these people getting a good experience and these people get a sucky experience.
01:04:54
Speaker
Yes, a hundred percent. Yeah, it's nice. I will as a parting thought. So I thought I should probably let you into this secret. A week ago, I thought I'll watch your Kickstarter video as like prep. It's half hour video. I thought I'll watch that quickly as prep for this podcast. And I still haven't got all the way all the way through it because every few lines I go like, oh, you can do that. And I go down my own little rabbit hole.
01:05:18
Speaker
Yes, nice. It's more of a meal than it looks, so thank you for that. No, that's great. We actually had a hilarious time. I recorded that on my stream, so we were live, and I was doing multiple takes, and I was trying to ask people, did this land? Did everyone get what I was saying here? We had to do a lot of takes, so I ended up taking
01:05:40
Speaker
I don't remember, eight hours or something like that straight of just recording to get down to the 30 minutes. I'm really glad it came across as like feature packed. That is, you know, I'm like, sweet mission accomplished. I think you may have given me more than eight hours of work. So I'll put a link in the show notes for anyone else that wants to slip down that rabbit hole. Awesome. Thank you. And I should probably go and get the next few snippets of wisdom from there now. So TJ, thank you very much for joining me.
01:06:08
Speaker
Yeah, no problem. I had a great time and hopefully everyone gets to have more fun while they're coding, whatever. However, you know, you find fun. That's what it's all about. Cheers. Thanks. Thank you, TJ. If you want to get started with NeoVim, take a look in the show notes for links to that Kickstarter config we talked about and the walkthrough video that TJ made, which is really interesting.
01:06:32
Speaker
If you vehemently disagree with my opinion on VimScript, I will of course respect that, but I've put a link in the show notes to VimScript's definition of true and false values. You can agree or disagree with me, but that is the moment it lost my heart.
01:06:49
Speaker
My opinions on Vim's script notwithstanding, I'd like to dedicate this episode to Bram Mullenar, the creator of Vim. I think it's such a generous thing he did to spend all those years working on a fantastic tool, and a tool that's been with me in one form or another for most of my career. Bram, thank you and rest in peace. You're a legend.
01:07:12
Speaker
And with that, I think it's just time to say, if you've enjoyed this episode, please take a moment to like, rate and share it. And make sure you're subscribed because we'll be back next week with more. For now, I've been your host, Chris Jenkins. This has been Developer Voices with TJ DeVries. Thanks for listening.