The syntax highlighting in NeoVim and Vim is great, but there's a better alternative. TreeSitter is a dedicated syntax parser designed to be fast enough for editors to use on every keystroke. It's faster and more reliable than the traditional methods used by NeoVim and Vim, and generally has better language support, because that's its main job. NeoVim officially supports TreeSitter, so let's set it up and see how it can improve our syntax highlighting, solve some issues, and give us some extra features. First off, let's take a look at the current state of things. I'm going to dive into a fresh Laravel project with Laravel Breeze, and let's jump into our User model.

I'm going to dive into a fresh Laravel project with Laravel Breeze, and let's jump into our User model. You'll see we've got syntax highlighting already, and it seems pretty good, but there are a few small issues. If I come down to one of these lines and I try to comment it, you'll see that by default I get these multi-line comments where there's an opening tag and closing tag. Now this is pretty easy to fix, so let's not worry too much about that one. And then if we come down to this doc block here, you'll see our type annotations don't have any special highlighting, they're just grey like the rest of the comment.

have any special highlighting, they're just grey like the rest of the comment. Again, not a huge deal. So let's jump into a view template. And for those that don't know, view single file components combine multiple languages into the same file. So at the top here we have JavaScript, and then underneath here we have this HTML-like template syntax. Now if I come up into this JavaScript section and I try and do a comment here, you'll see I get a HTML comment, which isn't going to work in JavaScript. And that's because by default each file can only have one type of comment string.

I get a HTML comment, which isn't going to work in JavaScript. And that's because by default each file can only have one type of comment string. So if I come down into the template section and I comment a line here, then that works fine. Now again, this is pretty easily solved without TreeSetter, but TreeSetter makes it much easier and faster. One last thing to note is the syntax highlighting of these attributes. For the class here, this one's fine, these are all string class names, but this v-if is an expression. So this is referencing a variable, same with this v-if, and then this href binding is calling

an expression. So this is referencing a variable, same with this v-if, and then this href binding is calling a route function and then passing in a string. But at the moment the whole thing looks like a string. So let's jump back to our .files repository, and we'll open up our plugins.lua file, and then let's come down to the bottom, and then we'll add the TreeSetter plugin here. So the main thing to note here is this run option. This will be called every time we install or update the plugin via PackerSync. And inside this function, we're calling the update method on TreeSetter. And this just keeps TreeSetter's language definitions up to date.

And inside this function, we're calling the update method on TreeSetter. And this just keeps TreeSetter's language definitions up to date. Now by default, TreeSetter doesn't enable any of its modules out of the box, so we need to create some configuration for that. And I've gone ahead and referenced a module. So let's go ahead and create that one at nvm-lua-user-plugins-tree-setter.lua. And then I'll paste in my basic configuration here. Now you might notice that sometimes I extract configuration to a separate module, and other times I keep it inline in plugins.lua. I haven't really figured out a good rule for this yet.

There is an auto-install option that will attempt to install the correct language any time you open a buffer. But I found that sometimes you actually want multiple languages in the same buffer, and the auto-install doesn't always do a great job of detecting this. For example, in PHP, we have the PHP language, but then there's the PHPDoc language for those doc blocks. And for our view files, we have the view language, but then we have JavaScript or TypeScript, and so on and so forth. So I just find it easiest to set it to all, but it does make our install process take a little bit longer.

Alright, that's done. So let's jump over to our Laravel project, and I'm going to open up a new split in Tmux here so I can open a separate Vim session, and we can compare everything side-by-side. So in this left session, let's just go back to our user.php, and then on the right here, we'll also open up that same file. And here you can compare the difference. Some of the colors are a bit different, which isn't a big deal, but the main thing to note is if we come down to this fillable property here, you'll see that the one on the right now has syntax highlighting for those type attributes. And if we come over to our welcome.vue file, so let's open that up on both sides, you'll

now has syntax highlighting for those type attributes. And if we come over to our welcome.vue file, so let's open that up on both sides, you'll see our syntax highlighting looks a bit different, but more importantly, you'll notice that down in this section here, the vifs and the hrefs all have syntax highlighting inside the quotes. They're no longer looking like they're just strings. One thing you might notice though is that there's a lot of spelling underlines in our code, and typically we only want spelling mistakes to show in things that are strings. I believe this has been fixed in the upcoming NeoVim 0.8, but for now there is an easy fix. If we come back to our .files, there's an additional option we can add under highlight

I believe this has been fixed in the upcoming NeoVim 0.8, but for now there is an easy fix. If we come back to our .files, there's an additional option we can add under highlight called additionalVimRegexHighlighting equals true. And this does make things a little bit slower because it uses some of NeoVim's built-in syntax highlighting, but I think it's worth it. So let's go ahead and we'll save that file. And then if we come back to our Laravel project, we'll quit out of this, and let's open that one back up again to our welcome.vue, and now those spelling mistakes have gone. If we come down into our JavaScript section and we do a comment, you'll see that we still have the incorrect comment type.

So this will use the context to determine what the comment string should be. We'll save this, but like with the built-in modules, we also need to come in and enable this one. So let's paste that in there, and let's do a packer sync to install that extra plugin. All done. All right, let's come back over to our Laravel project, and we'll quit out of NeoVim again over here and open it up. And now if we do a comment in here, you'll see we get our proper forward slash forward slash comment in the JavaScript section. But if we come down to our template section, then we still get our HTML style comment.

slash comment in the JavaScript section. But if we come down to our template section, then we still get our HTML style comment. This also has fixed our issue in PHP, where now the default will use the forward slash forward slash instead of the multi-line comment in here as well. Now there is one last thing I want to show you with TreeSetter. I mentioned that TreeSetter enables a lot of extra functionality, because plugins can hook into it and understand more about the document. So there is one extra one I want to install. So let's come back to our .files and back over to our plugin. And we're going to install this first-party plugin called TreeSetter Text Objects.

So let's come back to our .files and back over to our plugin. And we're going to install this first party plugin called TreeSetter Text Objects. And you might already start to guess what this is going to do. Once again, we need to enable this in our config. So we'll come down and we'll enable the text objects module, specifically the select module. And we're also going to use this lookahead function, which I'll describe in a second. But we're setting up some additional key maps, and these are effectively new text objects. So we have if for the inside of a function and af for the outer function or around the function. And then we also have ones for parameter inner and parameter outer, ia and aa.

function. And then we also have ones for parameterInner and parameterOuter, ia and aa. And these work similar to the built-in text objects we've already seen, like insideQuotes and aroundQuotes. So let's save that and we'll run packasync again to install that additional plugin. And now let's come back over to our Laravel project. I'll go ahead and quit this one again. And let's come back into our User module. I'm just going to go ahead and close this one over here because we don't need that one. Now if we come down to the bottom, I've added this promote function to our User model, where maybe you

I'm just going to go ahead and close this one over here because we don't need that one. Now if we come down to the bottom, I've added this promote function to our User model, where maybe you could be adding a rank and a title to your users. You'll see I can do via to select around the parameter or argument, whatever you like to call it. And you'll notice that I didn't have to have my cursor inside that first parameter for it to work. And that's what that lookahead function does. It'll jump forward to the next occurrence on the line. I can also do vaa to select around the parameter or argument. And if I come over to this next one, you'll see that vaa will select everything including that single quote.