Why Neovim?
source link: https://changelog.com/podcast/457
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Transcript
Changelog
Click here to listen along while you enjoy the transcript. š§
We are back for a follow-up episode to episode 450 on Vim. First of all, I wanna say that I appreciate all of the positive feedback around our Vim episode. Weāve put a lot of work into that, and it sounds like everybody enjoyed it. Weāre happy to hear that. And one of the things that weāve heard over and over and over again was āWhen Neovim?ā Similar to the Crypto Kitties say āWhen Moon?ā, the Neovim kitties were saying āHey, youāve done Vimā¦ Now give us the Neovim treatment.ā So by popular demand, we have TJ DeVries here to talk Neovim with us. TJ, thanks for coming on the show.
Yeah, itās my pleasure. Really excited to chat and just explore some fun topics together.
We are excited too, and I have with me not Adam Stack - it is Nick Nisi, my co-patriot at JS Party. Nick, welcome to the Changelog.
Hoy-hoy. Iām happy to be here. Excited to talk about Neovim. And just for the record, it wasnāt just me hounding Jerod to get a Neovim episode.
That wasnāt your bot just telling me over and over again?
I canāt confirm or deny that, but it wasnāt me specificallyā¦
Well, if you know JS Party, you know Nick is often trying to turn it into Vim party, and he brings up Vim whenever he has opportunity, and he has been for a little while a Neovim user. How long have you been on Neovim, Nick?
Itās been a couple years. But Iām a recent convert to the Neovim 0.5/Lua lifestyle, that Iām excited to talk about today.
[00:04:00.05] I will also confess that after our Vim episode and our Modern Unix Tooling episode Iāve been reinvigorated, and I installed Neovim. I threw away my vimconfig and Iām doing Survivor-style āWhich configs make it into the new config?ā game, line by line, and Iām having lots of fun. I feel like a kid again, just tweaking and changing, and kind of relearning how to use Vimā¦ Because Iāve been using it for a very long time, in a dual capacity, with a full-time GUI.
So I was on Sublime text for years, I switched to VS Code, and I always had Vim open in a shell, and I would use it on servers, and I would use it kind of casually. As you know from that episode, I always use vim mode whenever available, but I was not using it full-time as my programming editor until a few weeks agoā¦ So Iām back, and Iām giving Neovim a try, and Iām having a lot of fun. But TJ, give us some of the back-story here, because Neovim has been around for a while. Weāve never done a show on it, despite multiple cries to do soā¦ Who created Neovim? When did they start it? Why did this have to exist? etc. Give us the back-story.
Yeah, so I think the main person who first started it was Thiago de Arruda on GitHub. And it is probably about ten years ago; I donāt remember the exact date. The main thing that happened was de Arruda was really interested in getting some of the ability to run external jobs asynchronously from within Vim, and that was the first main pushā¦ And de Arruda submitted some patches to Vim Dev, which is the mailing list for Vimā¦ But unfortunately, at the time the patches didnāt work for Windows, and there were some other problems that would have broken compatibility with a lot of the places that Vim expects to buildā¦ So due to that, it was sort of like this struggle of ā I donāt know if āstruggleā is the right word, but just sort of a difficulty trying to figure out how these features could work within Vim and all the places that Vim needs to build, and the size requirements, and all these other things which are super-valid concerns to have if youāre on all the places that Vim can buildā¦ Like, do you wanna still be able to that? Thatās one of the selling points, the universalism of where Vim is.
You didnāt have an old Solaris machine to test it on?
Right, he did not make any patches that worked there. So basically at that point de Arruda was kind of like āWell, I donāt want to necessarily have to support those. I wanna do different things that can work differently, and I wanna push forward in some of these areas that might make us end up in a place thatās not the same place that Vim is.ā So de Arruda basically started Neovim, and then from there de Arruda also had several other large ideas in combination with people like Justin M.K, whoās still part of the project, as well as [unintelligible 00:06:51.01] whoās one of the largest early contributors to Neovim. And they added other things, like remote plugin support, and started doing Lua scripting, and things like that. But that was sort of the main branching point that started to allow Neovim to go down a separate path from Vim.
Exactly how different is it?
This is a pretty common misconception, that Vim and Neovim are very, very, very different. Vim and Neovim still share much of the same codebase. Neovim still ports patches from Vim, all the time. We have some contributors, especially like Jan Lazo, who in the last 0.5 release helped to get us to over 1,000 Vim patches ported from Vim into Neovim. So thereās still sort of like an insane amount of similarity between the two. And if you open them up, you wonāt really see in effect any differences from a lightly configured init.vim or vimrc, whatever you want. Thatās an important backwards-compat thing that weāre interested in trying to work hard on.
[00:08:05.06] Thereās some things that are removed from Neovim that are in Vim. For example, Neovim doesnāt ship with a GUI by default, like Gvim. Neovim removed all of the code that tightly coupled it to a GUI application, and instead implements GUIs over RPC. So thatās an example of like if youāre expecting to be able to just open up Gvim, but with Neovim - that doesnāt happen, because those two things have sort of been decoupledā¦ As well as various other things. If you installed Neovim, it wouldnāt install view, the command view, which is opening Vim in read-only mode, because you can instead do nvim -r, or something; I donāt know what it is off the top of my head. Sorry, everybody. But you could just alias that to be the same, and then it would retain the same behavior. So of course there are some similarities that are obvious at the start, and some things that are a bit different when youāre first encountering themā¦ But in general, thereās an incredible amount of overlap still between the two projects, I would say.
That would be my experience so far - I havenāt noticed a difference in just regular text editing. I could just alias it and never notice. Now, once Iāve started configuring it and trying to do some more advanced things, you start to see where the seams are, where the differences are. Go ahead, Nick - what were you gonna say?
I was gonna say something similar in that when I started using it I actually started using it I think for the same reason that it might have been created, now that Iām hearing thatā¦ And thatās because I heard about this async job supportā¦ And I had just gotten into configuring linting, and things like that. But every time it would lint, it would completely freeze Vim, and that was just super-annoying.
Then I heard about Neovim and how it could do that asynchronously, so I set it up, but I was just like āThis is just temporary. Iām sure Vimās gonna catch up, and Iām just gonna switch back to it.ā So I installed it and I did that alias, alias vim=nvim. And I still have that, and thatās still how I invoke it, but that alias is five or six years old at this point. Now itās just interesting that I really canāt tell the difference, or couldnāt tell the difference in the beginning, aside from where your config lies in that. But otherwise when you start up, instead of Vim it said Nvim, and that was pretty much the big difference.
Yeah. Just to mention as well, Vim does have those capabilities now. It does have asynchronous jobs, and other things; I just figured I wanna throw that out there, in case people are interested in adding some of those things to their own vimconfigā¦ But it does exist in both now.
Yeah, thatās one of the cool things that Iāve noticedā¦ I wonder if Neovim is directly to blame or to accredit for this, but it seems like Vimās development picked up with regard to performance asynchronization, and certain things that maybe werenāt being advanced, and maybe there was a little bit of ācompetition spurs innovationā thing going onā¦ That was just my casual observation. Is that your thoughts as well? Or if we ask Bram about it, would he say āYeah, I saw Neovim coming and I was like āHoly cow, I need to start doing moreā, or whatās the story there?
I actually think that this is probably a common misconception. I think Bram likes implementing things that he thinks people are going to use, and it wasnāt really clear from the community that this was an important thing for them to have previous to thisā¦ My personal opinion - obviously, Iām not inside Bramās head, and weāve only spoken just casually a few times on GitHub issues or email - is that Bram just was like āOh, thereās people requesting this now in vimdev, and theyāre thinking about it a lotā¦ Oh, we can implement thatā, and so then he implements it, and it works well, and then heās happy with the solution. Iām not 100% confident that Neovim spurred him on to do that. I donāt necessarily think that thatās exactly the case. I think itās much more that Bram saw that people in vimdev were like āThis is cool. We should have thisā and he was like āOkay, Iāll make one that works well for inside of Vimā, and then thatās what he did.
And to that point, both of them have async and other similar features, but have they arrived there in different ways? Is it different APIs, or ways to invoke async, for example?
[00:12:12.15] Yeah, so to start external jobs, the jobs APIs arenāt compatible. There are plugins that sort of wrap them to make them very similar, so you could have one thatās shared and you call mysharedlib.startjob, or whatever; you could be doing that and sort experiencing working them in bothā¦ But their implementations are different. Neovim is really focused a lot on building around LibUV, which is the stuff that I think Node (if I remember correctly) is built on top ofā¦ You probably know about that in JS Party landā¦ So Neovim event loop and stuff is built around that, and so we use LibUV bindings to do the async jobs and many of our other event loop type things that weāre interested in doingā¦ And I havenāt looked in-depth at how Vim actually implements it. If I recall correctly, theyāre not using LibUV. So the underlying implementation is not the same. But their APIs are pretty similar and itās possible to write code that works in both. Itās just sometimes a bit annoying, but thatās okay.
And with the help of those community plugins, is the burden on plugin developers kind of lessened, or almost non-existent by that? Or does that kind of cause some issues?
If all you wanna do is run a job asynchronously, then it is not incredibly difficult. There are other things that are much more difficult to maintain shims between, or some things that are very specific to Vim or very specific to Neovim that either havenāt been unified or never will be.
For example right now in Vim thereās APIs ā theyāre all prefixed with popup_. So thereās popup_create, or popup_menu, or things like this, and they allow you to make little floaty windows. Neovim currently doesnāt have those APIs, and we have not a shared floating window implementation underneath the hood, so itās not necessarily simple to just port the patches over and get the results. But Iām working on a project and other people are contributing as well to create Lua API that we can create windows with, and then we could expose a thin wrapper over that back in VimL thatās the same, or looks the same to the user, so that you could write plugins in Vimscript and they would work in Vim or Neovim, even though the underlying implementations arenāt the same. So itās not that weāve completely abandoned any hope of still making some things the same, but right now if you wanted to have floating windows in one versus the other, youāll have to write very different code. But if itās literally just like āI just wanna spin up a job and have it run externallyā, you could probably have that working for your plugin in like 5 or 10 minutes for simple cases, I would say.
So it sounds like the longer it goes, the less underpinnings they share. You mentioned that there was 1,000 patches or so in the 0.5 that were direct ports from Vim into Neovim. Do you expect over the course of Neovimās life that that number would decline over time, or do you think thereās enough foundation thatās shared that itās just always going to be massive amounts of shared porting, the solutions they come with over there, onto the Neovim side?
In general, I try not to predict the future too much, because itās a difficult game to play, butā
Well, what trend are you watching? Give us the trend.
Yeah. In certain areas of the code I would see us still porting patches for a long timeā¦ And port is in some cases very loose; it might be literally just applying style differences and putting them in, and then porting tests written in Vim into Lua, because we write most of our tests in Luaā¦ So some of those patches are very simple, and they are almost direct applications. So thereās some areas that I would expect that to happen for a long, long time. A bunch of things in like eval.c, which is where Vimscript things get done.
[00:16:15.17] Itās like āOkay, we simply just added this new argument to a Vimscript function. Okay, cool. We can try and port that over and then we can have that the same in both.ā But in other areas, there already exists no way to port patches. For example, for floating Windows code we have two separate implementations, so it makes no sense to port any of those patches that get marked as not applicable for Neovim.
But it may be that we in effect port some of those patches over in attempts to keep the community as close as we can, like with the example I gave of the popup APIs, where Neovim would still like to implement those so that people donāt have to worry about which one theyāre writing for, and they can continue serving both communities easily.
So letās talk Lua.
Yeah, that sounds good.
On the Vim episode I asked everybody what frustrations they have with the editor, and Gary Bernhardt said āVimscript.ā
Iām pretty good at complaining, so Iāll limit myself to just one thingā¦ [laughter] Vimscript. To understand Vimās relationship to its scripting language, let me contrast with Emacs. Emacs 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; 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ās also 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.
So this is something Neovim is taking head-on, isnāt it?
Yeah I think Neovimās choice of choosing Lua is what I would consider sort of like the de facto future of configuring Neovim. Not that it wonāt be possible to write Vimscript or that we will remove the engine, or anything like that. That is not happening. We will continue to support that and allow that to happen.
[00:20:15.20] I think Lua has invigorated a lot of people to be interested in both contributing and sort of being able to explore making Neovim more their own. Not only is Lua a programming language that has lots of external libraries that you can install, with LuaRocks, and things like that, and thereās a lot of other external resources for learning Luaā¦ But thereās also really cool things like LuaJIT, which allows for crazy performance thatās just like sort of insaneā¦ Weāll talk probably a little bit about Telescope laterā¦ But Telescope can find and fuzzy-sort literally like tens of thousands of items as youāre typing in one main thread attached to the UI. We currently have some stuff in progress to do a few things in a little bit smarter way, so it doesnāt blockā¦ But regardless, itās doing an incredible amount of work as youāre typing, and that sort of performance is just not possible with old Vimscript.
Itās true that Bramās working on vim9script and there will be performance improvements there. Thereās a lot of people I know that Iāve talked to personally that are excited to use Lua because thereās applications outside of Neovim, that are like āOh, I used this for scripting before in a video gameā or āIāve used this in whatever C applicationā, or āOh, Iāve embedded this here.ā So they have sort of like previous experience or future experience that theyād like to have with the language that maybe makes it more accessible and exciting for them, as well as being fast.
Give Neovimās architecture on top of LibUV, was JavaScript considered as a potential language?
It was, I think, considered, but discarded. JavaScriptās ability to be embedded easily inside of a C application is not considered one of its strong suitsā¦ As well as its minimalism. I mean, Lua can be run and is run inside of some Linux kernels. So the portability and the size and all of these other things are really great featuresā¦ As well as ā Neovim I guess pinned in a way to Lua 5.1, whichā¦ The language is complete; thereās no changes, thereās no new things being added to the language, thereās no things being removed, which is really nice for writing a plugin now and having it work in 15 years, as opposed to ā not throwing shade at anything JavaScript, but I feel like it is a common problem that I see people talk about on the internet, that āYesterday my Npm build worked, and tomorrow it does not.ā Not to mention changes within the language itself. So thereās a lot of things about Lua that provide an incredible match with Neovim. Like I said, embedability, size, portability, and the fact that itās sort of static are really great things for us in terms of shipping a small binary that can work in a lot of places.
Yeah, it almost seems like Lua was purpose-built for use cases like this one.
Yes, that is exactly what the design principles of Lua are; one of the primary design principles is embedabilityā¦ So yes, this is exactly the case where you would wanna use Lua. You do not wanna use Lua to write your ten-million-line monolith; that is not the purpose of the language. The purpose of the language is to be embedded inside of other languages to provide relatively safe and easy ways to script and extend something. Like, youāre not going to have a memory leak in the same way, or a memory problem with writing C to script your editor, or something like that. Thatās not exactly the same kind of fun experience, at least for me.
[00:23:58.06] Right. Now, Nick, I know that youāve been porting your vimconfig over to Lua in the last couple of weeks, because as TJ mentioned, Neovim - you can configure it in Vimscript, and you can also configure it in Luaā¦ You can have an init.vim or an ā is init.lua? Is it the same file name?
Yeah, you can have either one. You should not have both. Both Nick, you had both here for a while; I donāt know how youāve been managing that. What [unintelligible 00:24:21.13] in your experience? Because I donāt think youāve used Lua previous to this, is that right?
Thatās right, I have not used Lua before this, and I initially was hesitant to even start, because I was just like āI donāt wanna learn Lua. I donāt have any practical application for it.ā But then I was like, āWait a minute, Iām learning Vimscript. I donāt have any practical application for that outside of thisā¦ā [laughs]
The thing that really pushed me into it ā as Iāve mentioned, Iāve been kind of a recent convert to that. I know that a lot of people have been using nightlies of Neovim, I guess 0.5 maybe Iād call it, the Lua support version, for a whileā¦ But I only recently jumped on that and started using it, and it was because I saw some cool plugins that I wanted to use. So it initially just started out with me installing the nightly of Neovim, and then just having my init.vim and putting in a lua require to open up the configuration for a specific plugin, and be able to use that. And I kind of didnāt like that ā as I started adding more and more plugins, I didnāt like that I just kept calling out to Lua for that, so I just went in as an experiment to see what it would take to translate my at the time 600-something-line of init.vim into init.lua. At the end of it, it came out as 240 lines of Lua, which was really surprisingā¦ But thatās because I split out plugins into its own plugins.lua that set up all of thatā¦ But that was still only like 50 lines. I lost 200 lines in there somewhere, and I feel like itās more powerful now.
And thatās not like losing your car keys, thatās like losing weight. Thatās the kind of losing you wanna do.
Exactly. But I guess from your perspective, TJ, would you say that thereās a big benefit to converting your configuration to Lua, or is was the primary intention to be more like for plugin authors to be able to write more robust plugins?
Yeah, so thereās a couple aspects to chat about in that area. The first one is I donāt think that we have yet implemented everything in Neovim to make it super-elegant and easy to write your entire configuration in Lua. Thatās going to take time. I have a work in progress PR for auto-commands, for example. That would allow you to directly pass Lua refs inside, and Neovim in the C code will hold a reference to that Lua ref until itās ready to release it, and then release itā¦ But that requires a lot of changes. A story for a different day, if we wantā¦ But the point being - you still basically have to write your auto-commands in Vimscript, even if youāre inside of Lua.
Yeah. I have a lot of Nvim execs in there for that stuff.
Yeah, exactly. So that doesnāt really give you any necessarily gain. So thereās some parts of my config that are still in Vimscript, and probably will be for a long time. The other part too is if itās working really great for you, I donāt see any reason to change it over. Itās gonna work well to do a lot of the set operations or simple things like that. Vimscript is a DSL for doing those it will work probably nicer than we can sometimes do inside of Lua, although some of them have sort of been mitigated by things like vim.opt, which allows you to use Lua and metatables to set Vim options more ergonomically, I guess.
[00:27:47.05] So I would say there are things that are nice about setting up your config in Lua. You can use closures really easily, and thereās a lot of ergonomics about passing around functions or doing validation or whatever that isā¦ But I donāt see a whole lot of gain of just switching over to init.lua right now. I think a lot more of the benefits are about extending particular parts of your configuration. Maybe you have a complicated function that shelled out to some commands and parsed some strings and then it would do something within a certain buffer of a certain file type - well, that might be a lot nicer to write in Lua than it is in Vimscript. But changing set number to vim.opt.number=true - I donāt know, that doesnāt really strike me as āWow, thatās so mind-blowing!ā [laughs]
So maybe someday I would say without hesitation you should just port it over, but I think the primary focuses are much more about scripting the editor in a more deep and customizable way than just setting options, if that makes sense.
For sure. And yeah, I think that from that translation a big thing that I really liked ā like, yeah, auto-commands and things like that, Iām just likeā¦ Basically, itās just a string of Lua in my config thatās being run. But other things, like ā Iāve used a plugin for years called Vim Startify, that lets me configure what the Vim startscreen looks like, and it shows the recently used files, and things like thatā¦ But it has a big object that you configure and tell it exactly what you want it to show and do and all of thatā¦ And doing that in Vimscript - Iāve always just hated that syntax, because as you put things on a new line, you have to have the backslash on it everywhere, and it was just really annoyingā¦ But things like that, being able to use a Lua ā do you call that a table?
Yeah, a Lua table to hold all of that information, and then just be able to access it from Vimā¦ And I can do things like access other objects like that through the ā I think itās _G for globalā¦ And then being able to access from Lua Vim functions through vim.fn - that stuff is really cool, being able to do all of that. And I think that Iāll probably keep my config in Lua going forward, and just kind of adopt the new features as they come in, like being able to set auto-commands, and things like thatā¦ But yeah, right now thatās just glorified Vim in strings being called.
If someone was starting today and they made their config in Lua, I wouldnāt be like āSwitch it back to Vimscript. Itās betterā, or something. I wouldnāt really do the same vice-versa either. If itās working for you and youāre happy with the end result, thereās no reason to spend a bunch of time switching the language to be something else. I think theyāre both really good options for configuration at this time.
Yeah. I made the decision that I was gonna start it in Lua, because Iām like āIām starting fresh, Iām starting in Luaā, and then Nick showed me his, and Iām like āNah, Iām gonna go back to init.vim, because I can just copy-paste those right in when I want them, without thinking.ā
[laughs] Totally.
The other a little bit challenging thing is depending on if you spend your free time perusing dotfiles on GitHub, if you find something cool in Lua, you either have to translate it to Vim if youāre not using Lua, or vice-versaā¦ And understanding how to do that translation is going to be fun for everybody.
Not the most transferable of skillsā¦ You know, youāre not gonna put that on your resume. āI can translate configurations between Vimscript and Lua.ā Oh, wow.
Speak for yourself.
Speaking of translating Vimscript to Lua, thereās an interesting project that I have on my long-term horizon to explore that Iāve already written a decent amount of stuff for, which is trying to basically transpile Vim9script, the new language that Bram is making, into Lua, and then keeping as much of the semantics as we can between the two.
[00:31:51.04] One of my goals is like I would hope that we can keep Vim and Neovim as close and friendly as possible. No one on the Neovim team has any animosity with people on the Vim team, and I donāt really think vice-versa eitherā¦ So itās a long-term project that I canāt decide if itās real or not, or how much of my life I will devote to it. I have some preliminary things and I can generate valid Lua from Vim9script, so thereās still ā even in places where people might at first glance think that itās gonna be impossible for Vim and Neovim to live together and be friendly, I still have goals to make them be friends. [laughs]
Thatās interestingā¦ Because thatās been one of my lines of questioning that Iām thinking about here, is that Iām starting to see most recently ā weāll get into tree-sitter and things like that, but most recently youāre starting to see some pluginsā¦ Thereās one called Limelight, which is written in Lua, for Neovim, using tree-sitter for better dimmingā¦ And it was the first time ā because you know, I watched a lot of these things, what people are working on etc. for Changelog News, and a lot of times itās like, this is a Vim/Neovim thing, and that was like for years. It was either Vim-only, or Vim/Neovim. And Iām starting to see like āThis is a Neovim thingā, and thereās no Vim equivalent. They didnāt take the time, whatever you had to do to write it twice, or whatever it is.
So I started wondering, will that start to pull people away from Vim onto Neovim? And itās interesting, your perspective of like, you donāt necessarily want that to happen.
Yeahā¦ I mean, some of them are just impossible, at least today. Thereās no way to get tree-sitter, or at least that I know of, inside of Vim. So no matter what you do, if you wanna build something on top of tree-sitter, which is a really powerful and interesting technology, thatās gonna most likely end up being Neovim-only plugin.
And even for me ā I will probably talk about Telescope a little bit, but Telescope is Neovim-only, because it uses a ton of Neovim-specific APIs that are only available in Neovim, and uses the window things in complicated and interesting ways, and it relies heavily on the fact that you have LuaJIT installed, and uses native C modules that we can link against C, that optionally you can use to do sorting to make sorting even fasterā¦
So I think there will be plugins that exist that are only for Neovim, and there will be plugins that exist only for Vim, and thatās fineā¦ My goal, and the Neovim team goal, as I was trying to say before, is basically just like, weāre not actively trying to make the community not work for both.
Well, I really appreciate that perspective, because so many times when there are projects and efforts like these, so often itās like a hostile takeover kind of a thing. Or itās a [unintelligible 00:34:40.02] like āWell, weāre gonna slowly take overā¦ā At the end of the day itās Vim. Itās a different Vim, itās a newer Vim, itās got things Vim doesnāt have, and it takes things outā¦ But still the same editor that we all know and love, thatās been around for all these yearsā¦ Like, why would you wanna crush that? Why would you wanna kill it?
Yeah. And I respect Bram a lot. Heās made an incredible piece of software, and itās pretty bonkers if you just think about where it started to where it is now, and all the things that heās done for itā¦ Plus, Neovim is literally a fork, so itās like, we share a bunch of code that we never wrote. I donāt know, if feels kind of not very grateful and not very thankful to just be like āAnd now weāre our own thing. And I donāt like āā You know, itās like an angry teenager, like āI donāt even like you, dad!ā [laughter] Itās not exactly like the pinnacle of maturity necessarily all the time to have that kind of situationā¦
It frustrates me when I see it online between people as well. Itās just like, if they wanna use Vim, thatās cool. Why would you be mad about that? That just seems cool to have them do that. Thatās great.
Yeah. If youāre gonna hate on something, hate on the Emacs people. Come on, whatās wrong with youā¦?
I mean, Emacs is now closer to Vim and Neovim in spirit than many other places, right? Not to name any other names obviously, butā¦ [laughter]
[00:36:05.16] Yeah. They need to join forced to take on the onslaught of the graphical editorsā¦
[laughs] Exactly.
Oh yes, the evil of graphical editors from faraway landsā¦
In my browser nowā¦
So Nick, you mentioned that you were waiting for the Lua stuff to land or to be officialā¦ 0.5 came out this summer, July 2nd, I believe. A huge release. 4,000 commits. As Iāve mentioned before, a thousand of those were ports from Vim, but lots of new stuffā¦ And the community rejoiced. I mean, this must have been a long time coming TJ. How much work went into this release?
Yeah, there was a lot of work. There was probably ā if I had to take a guess, probably 3-4 weeks of time of me just answering when will Neovim 0.5 come out; you know, just replying to messages like that online. [laughs] We started a meme on my Twitch channel; when people would ask that, we did [unintelligible 00:39:05.18] and then that took a both command back and it explained that every time someone asks about Neovim 0.5 release, the release has to be pushed back one day. [laughs]
But in all seriousness, itās been a long time coming, and it was a culmination of a lot of really long-term project and vision that the team had. I canāt take credit for all of it, or even probably I canāt take credit for most of it, or anythingā¦ But seeing things like the LSP come to fruition - thereās some fun history there, where you can go dig up some of the original issues, and my first PR probably in 2016 or 2017, where I proposed a lot of the first ideas about how we would put LSP inside of Neovim and have it be in such a way that it still is the spirit of Vim, that itās not āWeāre trying to smash everything in here and reimplement every wheel that we can. How can we do it in that way?ā
[00:40:08.19] So for me, itās been very fun to see that finally released. Itās been in my head for a long time, and other people who helped along the way, to finally implement itā¦ And then as well putting in tree-sitter, which has also been sort of a long-term vision about making Neovim as an editor understand the text at a much higher and more interesting or semantic level than just strings of characters, which is one of the goals of tree-sitter.
Letās focus in on LSP, the Language Server Protocol. This one didnāt make the Vim show, but I did ask each person what they FOMO-ed from other editorsā¦ And we wanted to keep it tight, so we dropped that section out, but Iāll tell you, Drew Neil mentioned LSP specifically in VS Code.
Yeah, well ā I come back to language servers againā¦ About a year or two ago I started learning TypeScript, and I know that TypeScript has a very good language server. Pretty much language server and VS Code and TypeScript were all kind of invented under the same roof, so theyāre very well integratedā¦ And I knew that I wanted to understand what a good TypeScript development experience is, and so I made a decision not to use Vim while I was learning TypeScript. I thought, okay, VS Code is an editor thatās very well positioned for beginners, and while Iām being a beginner in TypeScript, Iām gonna be a beginner in VS Code as well, and just learn the way that a good language server integration would feel like, so that I can sort of take that learning and bring it back to Vim, so that when I make that step of āOkay, Iām gonna now switch all my TypeScript development back over to Vimā, I know what Iām looking for.
For those who donāt even know what LSP is, could you just explain what it is, where it came from? And then weāll talk about it in the context of Neovim.
Yeah, sure. So LSP is a protocol designed by Microsoft; itās actually one of Microsoftās VS Code users to communicate and basically get the language smarts that it hasā¦ Its big goal is ā if you think aboutā¦ You have m editors, in n languages, and when you wanna implement support for the next language, you have to implement that m times, right? So I think as developers, weāre very familiar with m times, n problems being very difficult and feeling intractableā¦ And also not fun to solve, right? Because even if you solve it once, you feel youāre gonna have to solve it n times again later.
So LSP is basically a protocol designed to talk from editors to some sort of server thatās giving you information about what youāre editing. So if you have your cursor on somewhere in a document, you can say āHey, whatās the definition of this?ā And so thereās a protocol, [unintelligible 00:42:57.13] You send that over the wire to something thatās running. It could be anything you want; it could be on your machine, on another machineā¦ It doesnāt matter. Itās just a protocol that you send over the wire and ask āHey, whatās the definition of this text document at this position?ā and it will return you back a list of possible definitions, or one, whatever the result is, and youāll be able to go there in the editor. So the editor will receive that response and know what to do.
This is really powerful, because in theory - itās not always exactly like this - itāll turn the problem from m times n to m plus n, which is a much better problem to solveā¦ And itās probably more like m plus n plus z; thereās some extra work still that ā
Yeah. It still has to happen. Some language servers have specific commands that only make sense for their language, or things like thatā¦ But thatās okay; thatās still a much more fun problem to solve. Thatās sort of the basics of what happened. And in the context of Neovim, what we saw was that this is sort of in a lot of ways just like an interface to your editor, and that was one of my big pushers for how we should think about LSP inside of Neovim, is this is really just defining a standard way that is shareable between other pieces of technology in how you can talk to your editor.
[00:44:17.22] I recently implemented something for my work at Sourcegraph, where I implemented a go-to definition over LSP, but what it does instead of running something locally - it asks this external program where the definition of this thing is. So that was basically a way for me to do that. And I didnāt ā I mean, obviously I knew how to move to the file and all these other things, because I am familiar with Neovimā¦ But it doesnāt have to be so. So it allows this interface to do.
And then if I can do another plug for Lua in here - the way that we did this with Lua is that itās very easy, because everything is just a function. You can replace a function with a basically set of parameters, and an expected thing to happen, and replace it with some new behavior thatās more suited to your purpose. Iāll give an example for that, which is in Golang we have a bunch of stub or test implementations for some interfaces that we have at my work. I donāt want to jump to those when I hit Go to implementation, 99% of the time. So what I did was I can ask the LSP āHey, where are the implementations of this?ā
I wrote some Lua code that walks through the results and says āIf this file ends with _test or _mock, discard it, and throw that away from my results.ā Generally at work we just have one result that remains, and then I just jump straight to there if thereās only one left, otherwise I open quick fix list.
So thatās really cool, because now I only have to press the button to jump to that implementation and it does exactly what I hope, only in Go code; and everywhere else it does the standard definition. So thereās this concept and idea of like - the way that we wanted to design it was āThis is just an interface for both language tool makers and editor tool makers to be able to interact with in a way that you can customize it to be just the way that you want.ā
Good explanation.
Itās just amazing. Iām trying to think of ways that I might implement this.
Nick, sometime youāre welcome to come on my stream and we can work on implementing it for you, or something; itāll be fun. For some other case.
Absolutely. Thatād be a lot of fun.
That does sound fun. So tell me about this client-server situationā¦ Is this like a network server, or is this like an embedded binary that you call? How does it actually talk? Explain that.
Yeah, so LSP - the primary modes that people use to communicate are either just standard in, standard out, or you can do it over TCP. Generally, if youāre doing it over TCP, people just use some pipe and then pretend that itās TCP, or something like that, instead of actually doing TCPā¦
[laughs] Rightā¦
But Neovim doesnāt care whatās on the other side. We take a list of commands, we spin up that thing, and start it, and then we have standard in/standard out between the two, and we just send basically JSON over the wire for a request, and then theyāll send JSON back over the wire to get to us, and itās just like a pipe, generally speaking. Itās possible to do other things.
So you could have anything on the other side. For example, gopls, the Go language server, is written in Go, and so itās just a Go binary on your machine that you say āgopls start upā, you send basically a configuration request, so it can understand what directory am I in, whatās part of this project, all those kinds of things. Thatās part of the protocol to understand. And then it will just respond to requests as you send it.
[00:48:01.03] Thereās also things like Microsoftās Pylance, which you can only run in VS Code, due to licensing concerns, but thatās written in TypeScriptā¦ So itās not written in Python, it just does the analysis in TypeScript and then sends the responsesā¦ But youāre just editing Python files; you donāt care what itās written in, itās just a protocol that talks between the two.
So letās say I wanted to teach Neovim a new languageā¦
Letās say I had a language called Ink, and I wanted it to understand Ink. Would I then provide my own LSP, or would I plug something into the LSP that Neovim ships with? How would I get it in there?
Oh, so maybe I should take a step backā¦ So Neovimās LSP client is just Lua code thatās inside of Neovim.
Itās an LSP client. It does not have its own language server in there.
Right, thatās correct. So it doesnāt know how to answer any of the questions. It only knows how to askā¦
I thought maybe it had a set number of language that it already had all of the stuff ready to go.
No, it does not. We have nvim-lspconfig, which is just like a repo that helps you get some of those running, but you need to figure out how to install those and make them executable on your machine. Being a package manager is not what weāre good at. Weāre good at being a text editor.
Someone else can figure that out and do that, and there are various plugins to help you installā¦ But Neovim just has basically a bunch of Lua code that knows how to handle the responses and ask the right questions. You need to install separate executables to do that.
And to that end Iām using something called lspinstall, that handles installing those and then using lspconfig to configure them for Neovim.
Yeah. Itāll just install it for you, and stuff. So we leave that to other people; you can handle that. Iām sure thereāll be one for specific distros, or specifically for Nix, or thereās one for Docker containersā¦ Thereās a lot of different ways that you can do that thatās not our strong suit. We try and make text editors good and fast. [laughs]
Gotcha. Well, letās move on to tree-sitter, because another cool technology ā they seem like theyāre similar, right? I mean, youāre talking about the syntax tree, about languageā¦ Help us understand tree-sitter and how itās different than LSP.
Yeah, so this is a really common question, so itās a good one, for sure. A really high-level way that you should start thinking about both technologies is that tree-sitter only deals with one particular file, and it only deals with the text that is in that file. It has no additional information. An LSP operates much more on like a project-wide level. Itās gonna open up and read all your files. Itās gonna index all of them. Itās gonna put a bunch of things in memory, and then itās going to be able to have some specific way that you can ask certain questions, and it will give certain responses. So thatās the first aspect.
The second aspect is tree-sitter is built in a lot of ways specifically to run inside of your text editor, as opposed to an LSP, which is some external process. So tree-sitter at a high level, for those who donāt know, is effectively a library for writing error-recovering incremental parsers, and itās very good at doing that, which is awesome for text editors, because most of the time when youāre writing code the code is broken. If you type a line of code, until you get to the semi-colon in C, it is broken. So you want to write parsers that can recover and not drop highlighting for the rest of the file, or do things like that. You want to actually do error recovery and smart error recovery. And thatās quite difficult to do, but tree-sitter just sort of gives you that for free if you write a grammar in the correct way.
So thatās the first part. And then the second bit thatās very important is that itās incremental. So it does not reparse the whole tree, which is awesome for when youāre typing keystrokes in a very large file, because youāre going to smash 80 keystrokes; you donāt wanna reparse the entire file 80 times, instead of actually just incrementally parses the things that it needs to and generates a new tree. Does that make sense so far? Any questions there?
Okay. So once again, tree-sitter only focuses on exactly that file. So this is cool, because this lets you do things like ā you can request highlights for the file by asking the tree questions, and basically getting back named nodes. You can write queries in this scheme-like language; it will return to you named nodes, and then in those nodes they have ranges, and so you can color them in your editor if you want. This is sort of like the thing that everyone recognizes about tree-sitter, but I find somewhat like the least exciting of all of the tree-sitter technologiesā¦ But it is the most obvious, and it also makes sense from a performance perspective that you would like to only change the highlights that need to be changed.
So this is like a really great improvement, and it allows you to write much better and powerful syntax highlighting than you could with just regexes, which is like the built-in Vim syntax engineā¦ And it prevents you from getting these situations where ā I donāt know if youāve ever had this, but in certain complicated file types if you scroll down the page sometimes it thinks everything in the rest of your file is a stringā¦ And youāre like āWhat is happening?! Why is this all a string?ā That canāt happen when you have a tree. Thatās not going to be an option.
So thatās sort of like the first level of tree-sitter. And it doesnāt communicate over the wire. Tree-sitter is running inside of Neovim. Itās embedded inside of Neovim. Now, the parsers and the queries and things like that - those are external to Neovim, and can be configured by users. I have my own custom grammar for Lua to do some special things etc. So those are all sort of configurable, but the engine itself is built into Neovim.
And is the engine something that was built by the Neovim team, or are you actually embedding somebody elseās ā is tree-sitter its own project?
Yes, tree-sitter is its own project. It was originally made for Atom, but several other editors now have used it because it is designed to be a library to be embedded inside of other editorsā¦ So itās very fast and performant, and theyāve spent a lot of time making it really awesome, and the tree-sitter team is super-cool.
To get started with it, kind of similar to lspconfig, you have to install a separate plugin. Is that just to help with the configuration then? I think thatās where I had confusion, was because I was like āI thought that it was built-in, but I have to install this plugin.ā
Yeah, so to be clear about it - you actually donāt have to install plugins for either. You can start up the server by yourself for LSP. It just is a little bit more boilerplate, so thatās why we have lspconfig. But itās certainly possible to do. Lspconfig literally only has configurations.
But for tree-sitter you also donāt necessarily have to install the plugin. Itāll just be more complicated. It would involve you downloading a grammar file, running tree-sitter to generate the bindings, because itās a separate executable to generate these bindingsā¦ And then creating your [unintelligible 00:55:14.05] shared executable and then putting that in the right place. So you could do that, and then the engine thatās built inside the Neovim will see that shared executable loaded up and appropriately attach it, I guess, to the bufferā¦ But that is not very fun to doā¦ [laughter] So thatās where Nvim tree-sitter comes in. Over time, we hope to upstream more of Nvim tree-sitter into Neovim coreā¦ But thereās a certain level of backwards-compatibility and polish that we wanna have in the core repository, and we felt that that would really hold back a lot of experimentation and interesting things happening. We tried to squish that all inside of Neovim core, which is where Nvim tree-sitter sort of came out as a separate plugin.
[00:56:05.16] So the engine, all of the interior things to do, like get the tree and have it parse incrementally as you type in all of that kind of stuff - thatās inside of Neovim all the time. Someday my goal would be we would at least ship tree-sitter grammars inside of Neovim for C, Lua and Vimscript, because those are the languages that Neovim deals with, and I think it would be cool to have a really awesome experience out of the box for those languages for peopleā¦ But weāre just kind of far away. I donāt know how far away we are, but we are not there yet to be able to do that.
So it sounds like tree-sitter is driving a lot of the innovation around these cool, new plugins that I keep seeing that are Neovim only, not Vim as well, because of the tree-sitter support.
Yeah, I can give you a really cool example of a few things that people have been doing with tree-sitter that are much further beyond just highlightingā¦
So a relatively straightforward and easy to understand one is a plugin called nvim-ts-context-commentstring, I think, off the top of my head; I donāt remember exactly the name. But what it does is tree-sitter tells you what language you are currently inside of, and those languages can be embedded in side of the same file. For example, in JavaScript land you can have React elements, so then inside of there youāre kind of like in React ā or I donāt really know how any of that works, because I like backend languagesā¦ But all of a sudden Iām like āAm I reading HTML? I thought this was JavaScript. I donāt know whatās going on.ā But one thing thatās kind of annoying is if you use a commenting plugin and you try and comment something in the JavaScript part, versus the HTML style part, youāll comment them incorrectly.
So nvim-ts-context-commentstring - all it does is itāll just update the comment string option, which is a built-in option, depending on which language tree-sitter currently detects. So if it detects that youāre inside of JavaScript land, itāll set it to // %s. If it detects that youāre inside of HTML, it sets it to the long HTML thingy thatās annoying to type. [laughs]
Thatās cool.
That one just honestly rocked my world, because Iāve had that problem in my life forever.
Yeah. And so this is even cooler, because it doesnāt just work for those languages. In Lua you can write FFI code, which is actually C, and it is somewhat deterministic how you start and end those cdef blocks. So you can actually write a tree-sitter query that tells Neovim āHey, inside of this string itās actually C code.ā So you get C highlighting in this random string in your file that you werenāt expecting, and then if youāre using nvim-ts-context-commentstring and you comment out a line in there, it comments out that line like itās C code. So itās very powerful to be able to do something like that. Itās very exciting.
Thatās awesome stuff.
Thatās one example. Iāll give you another one that I think is for me very fun. I use a snippets plugin called LuaSnip and itās kind of interesting. Iāve just been exploring that latelyā¦ But it allows you to sort of run Lua code as youāre expanding your snippets to sort of generate what the next text should be. So if youāre familiar with Golang at all, you know that if you write āif err!= nilā like ten thousand times a day - maybe thatās an understatement; I havenāt profiled myself yet, but I think itās somewhere around thereā¦ And what you do inside of those err!= nil sections is you have to write return, and then the type signature basically, with the default values. So if you return an int and error, then you have to do like [unintelligible 00:59:54.19] So you write this thing a ton of times.
[01:00:01.17] So I actually wrote a Lua snippet that will ask tree-sitter basically - it has a custom query that I wrote inside of Golang that will ask tree-sitter āHey, what is the return type of this function?ā So it can query the tree, it gets back the current node that youāre in, it asks for āHey, what is the nearest function scope that Iām inside of?ā So itās not a regex. It works for in-lined functions inside of another function, all these kinds of things. It asks for that, it gets what the return signature looks like, and then it generates the snippet in the corresponding things with the default values, and then err.
So itās very cool, because I can just type āieā for if error, expand my snippet, and correspondingly, the right signature is generated as a return value. These are the kinds of things that make me very, very excited about tree-sitter, and why I say itās cool to get better highlightingā¦ We look at our highlighting all day, and thatās very funā¦ But for both LSP and tree-sitter the things that Iām most excited about, especially on Neovim core team, is weāre trying to design interfaces that empower people to have much stronger tools and understanding of the code that lets them extend their editors in very unique and interesting ways, which is like ā I think the snippets one is a fun example of being able to do that.
Goodness gracious. That is really neat. Weāre getting tight here, but weāve teased Telescope a few timesā¦ Letās hit the nail on the head. Tell everybody about yourā
Letās peer into it.
Ooh, there you go, Nickā¦
Thatās why we pay you the big bucks.
[laughs] So Telescope is a fuzzy finder that I started and Iāve had a lot of contributors to over the past year. I cannot thank enough the contributors to the project. In just over the last year itās gotten over 3,000 stars and nearly 130 contributors, and I think that by itself is somewhat of a testament to how accessible Lua is, how interested the people are to extend the editor and to continue working on it, and their ability to pick up little pieces and do itā¦
But in terms of what Telescope is and why I made it - I partially made it just to explore writing some stuff in Lua as a way to push our API and boundaries to find out what we should be including in Neovim core. But as I was working on it, some of the things that Iāve struggled with doing in the past with fuzzy finders I just wanted to try and solve.
For example, I love fzf. Itās a very awesome tool. I use it all the time on the [unintelligible 01:02:38.22] but itās very difficult to do something like pass a function through fzf, because you have to encode it in some way, and then decode it again later, because fzf processes standard in and standard out. So Telescope is all Lua from the top of the stack down - or FFI, but that still countsā¦ [laughs] So you can pass a function reference, which might be what you wanna do if this item is selected, at the beginning of your code, and then you can pass that all the way through. And so when you select it, you can do something with that item.
So my main goal for making it was just to basically create the most extensible fuzzy finder that I could imagine. Every part of Telescope is configurable. The sorting algorithm is just an interface of a function, so you can have fzy soring, fzf, strict matching, n-gram matchingā¦ You can write whatever you want to do, and you can just plug that in, and that will just work with everything else.
The previewers are all just Lua functions, so some of them ā like, if youāre previewing buffers, it just literally opens the preview in a Neovim buffer, so you get exactly the same highlighting as you would if you open the file, because it is literally you opening the file.
[01:03:59.17] The ability to sort, and how youāre sorting those, and when you filter them - those are all configurable. The display, and UI, and different themes - theyāre all individually configurable, and what my goal was was to make the most configurable fuzzy finder that I could do, with an easy API to basically plug in whatever you can imagine that you wanted to sort on, and then use it.
So on my to-do list was to yank Nickās fzf Neovim setup and use it for myself. Should I just bypass that? Is Telescope ready for me? Should I just use it right away, or is it still baking?
Yeah, so thereās a couple things still baking for sure in Telescope. I mean fzf is just like a rock-solid piece of software thatās super-cool. If youāre doing things that might be searching millions of files, for example, you should stick with fzf. Go is going to be a better solution for you than what I can do in Lua, at least today. Weāll see. Maybe someday itāll be different.
We are nearing completion of merging a very important PR that will greatly improve performance for really, really large searches, like 500,000 items; it will still feel fast and not really block the editor. So itās up to youā¦ I would say if your primary concern is speed, then you should probably stick with fzf, at least for a while. Maybe you can talk to me in a year and maybe I feel Iām close enough to fzfās speed to say that weāre there.
Weāre working on some projects in C to compile as optional dependencies that you can throw in here and work super-fast and coolā¦ But weāre not there yet, and itās cool. Like I said, I like fzf, but I use it every day; I no longer use fzf inside of Neovim. I have lots of friends who no longer use it inside of Neovim, or other fuzzy finders. They just use Telescope.
So I would say itās ready for daily use, but if youāre gonna be searching ten million things or something like that, then running something inside of the program that youāre doing is probably not a good call. You should use an external executable thatās gonna manage that memory a little bit tighter.
I have an answer for youā¦ Why not both?
Yeah, I have recommended that for some use cases for peopleā¦ Like, if theyāre trying to grep every line in their very large monorepo, thereās no reason not to keep fzf around, at least for a while.
For me, I have a hard time if the UI isnāt as consistent. Itās just sometimes I notice that, or Iām like āOh, itās not the same as what Iām used to.ā So for some people, that really bothers them, and I understand; thatās totally cool, and they say theyāre gonna stick with fzf, and I say āAwesome. Thatās great.ā
That is one thing that I think Telescope really has going for it, is it just has a really beautiful UI.
That does help, doesnāt it?
Yeah. It is very interesting when you actually start using it and you notice that you get exactly the same colors as what the rest of your editor isā¦
I donāt have that with fzf.
Yes. It is not possible as far as I understand, because for example, when you open up a buffer inside of Neovim and if you have tree-sitter, it will literally tree-sitter highlight the same way, with the same exact colors, because it is just another buffer. It would be like if you did :edit this file; it will show it like that in the preview.
Very cool. So one thing I wanna touch on maybe as a closer - I mentioned the enthusiasm around the 0.5 releaseā¦ I mentioned how many people said āWhen Neovim on the Changelog?ā Thereās a lot of people very excited about this project, they love the ability to write plugins in Lua, they like the new capabilities that tree-sitter is making available to themā¦ Maybe speak to the community a little bit. I know you lead some livestreams, thereās a lot of fun being had, thereās celebrations around the big releaseā¦ And then maybe give waypoints for people who would love to get involved with Neovim, the community, where does it gather etc.
[01:07:56.23] Yeah, so we did a 0.5 release stream on Twitch, on my livestream channel, and the excitement and enthusiasm was really mind-blowing for me. You know, Iāve been working on Neovim for a long time, and sometimes youāre sort of just working and youāre pushing stuff to GitHub, and like āOkay, cool. Somebodyās using it, Iām pretty sure.ā But we had like 500 people there live to do the release drop on my stream, and it was really crazy for me, and people were showing a lot of supportā¦ So it was very exciting, even just getting messages from people saying āThanks.ā
Just as a general note, if youāre using open source software, and especially if itās maintained by people who arenāt getting FANG-like salary to do the maintenance, it means a lot when you get a thank you, or like āWow, I really like thisā to that. I was really pleased to see Neovim in the top spot for most loved editor in Stack Overflow 2021 survey. A little shout-out thereā¦
But yeah, I think the community is great, and itās really exciting to see how much people are excitedā¦ And Iāve really appreciated it and itās been fun being on the receiving end of that.
In terms of where can people get started and how can they help - first thing is weāre on Element, or Matrix, I guess; thereās a Neovim chat there. I believe itās linked from the readme. If itās not, then it should beā¦ [laughs] So you can go there. Or itās on Gitter, or itās on IRC. Theyāre all sort of bridged to be the same place, and you can hang out there and chat or ask questions.
Thereās a lot of issues that if you commented on and said āI wanna work on thisā or āHow can I fix this?ā, people are super-glad to help. Thatās how I got involved. I did a PR maybe during my senior year of college, adding a new thing to status line, and I just had a ton of really nice people be there to help and to encourage me and give me advice, and theyāve helped me grow a lot as a software developerā¦ Even on just that one PR, it taught me a lot of really great things.
I hope, and I think itās a goal to other maintainers as well, that we basically make a welcoming and happy place for people to learn a lot more. So donāt be afraid to ask questions or to comment and say āIād love to work on this. Where should I start?ā Thatās how I got started, so I think thatās a really great way to go.
Thereās some labels, like āGood first issueā or āMentored projectā or things like that that you could look into, but donāt be afraid to leave a comment or say hello. Weāre super-happy to see you. Or just say āThanks for working on it.ā That always makes me feel better and gives me energy to keep on improving Neovim and working on it.
Awesome. Well, we definitely appreciate all of the work that youāre doing. Iāll just echo your sentiment - if you have a piece of software that you use and love, find the people that make that software and let them know, especially if itās open source, but proprietary as well; thereās people behind the scenes of proprietary software, putting the work in. So thatās definitely appreciated.
Nick, I wanna thank you for being my Changelog co-pilot. Hopefully, none of the things you generated today were GPL codeā¦ [laughter] But happy to have you here with me. I think I broke the show with that one.
TJ, we really appreciate you coming on the Changelog. To everybody who requested this episode, we thank you as well. We do take requests. Head to our website, Changelog.com/request, fill out the form there, let us know guests youād like to hear, topics youād like to hear, if you want Nick to come back, if youād like us to banish him into eternityā¦ Let us know. We like to hear from our audience.
Any final words, TJ or Nick?
Just thanks for having me. Itās cool to see Neovim be requested on the show, and Iām always happy to talk about it. If you wanna see more of me or hear my voice, I stream a lot on Twitch.tv/teej_dv. You could come hang out there. Weāre live pretty often, and I do a lot of Neovim-related work there. Otherwise, just glad to be here, and glad to be participating in such a fun community.
Yeah. And thanks for having me on as well. TJ, I would gladly take you up on that offer to dig into some custom LSP stuff. Thatās really cool.
We are tentatively planning some related livestreams. We have nothing locked in, but definitely follow TJ on Twitch, and maybe on Twitter as well, for announcements. Of course, follow @changelog on Twitter. You can also follow Nick Nisi on Twitter, butā¦ I donāt know; you decide if you wanna do that.
Thanks, Jerod.
Alright, thatās our show for this week. Weāll talk to everybody next time. Sorry, Nickā¦ In true JS Party fashion I had to roast you a little bit, just at the end.
Absolutely. [laughter]
Changelog
Our transcripts are open source on GitHub. Improvements are welcome. š
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK