Use tree-sitter for deciding on adding `end`

[jemmyw]

I'm opening this PR as a discussion rather than actually looking for this to be merged.

I got frustrated with endwise adding end all the time when I'm writing examples in comments. I thought there would be a simple fix, but I got to thinking about other times I've been using it where it doesn't quite do the right thing.

In this modified version I've swapped out the regex parsing with tree-sitter. It should be possible to then extend this code to do something similar to the current version, but more reliably using the tree-sitter data structure. However, it actually works pretty well with the stupidly simple algorithm of "is the program invalid or would it be valid if I add end to the next line?"

It would also solve the problem of adding other languages as per the TODO as it's just a case of bundling the tree-sitter module.

https://user-images.githubusercontent.com/8016/134095516-8321d77a-fb34-4012-bb4b-f4e430cb47b6.mp4

[vfonic]

Hey @jemmyw!

This PR change is a great idea!

I tested it out and it seems to work pretty well! I couldn't make it work in files containing endless methods or omitting keyword arguments, but at least it stopped adding end statements after commented-out code.

Endless methods is a new feature since Ruby 3.0 and omitting keyword arguments is added in Ruby 3.1. Could it be that tree-sitter doesn't support these Ruby versions yet?

Thanks!

[vfonic]

Yes, the issue is at tree-sitter-ruby's end. I've posted an issue in their repo: https://github.com/tree-sitter/tree-sitter-ruby/issues/219

[alfuken]

@jemmyw can you, please, release your version on Marketplace? Or release a compiled drop-in replacement with your changes? Current version, if used with GitLens (or at least that's what the extension bisect says), creates immense lag on each "enter" keypress for me, up to 1s, and I was hoping that your version would behave better in this matter.

[jemmyw]

Hi @alfuken I haven't had a chance to go back to this and make any improvements so it might just act pretty rough. Here is a link to a release where you can download the vsix file and install that into vscode https://github.com/jemmyw/vscode-endwise/releases/tag/tree-sitter-0.0.1

[alfuken]

@jemmyw thanks a lot! 👍

[ndbroadbent]

This is pretty cool! @alfuken and @jemmyw, are you still using this branch, and is it working well for you? I'm tempted to switch if it is better than the current implementation. But I actually haven't run across too many examples where it's doing the wrong thing.

Are you talking about =begin and =end comments? I tried it out and I feel like it's still useful to add end automatically in those. Or other kinds of comments?

[vfonic]

I've made a fork which adds a new line first and then checks whether the end keyword is needed or not.

For example:

Before:

def asd|end => | being the cursor position

If you press ENTER here, it will change the code to something like this:

def asd
  |end
end

After the fix:

def asd
|end

It's not perfect, but better than inserting an extra end keyword.

https://github.com/vfonic/vscode-endsitter

@jemmyw feel free to pull in this commit into your extension.

[ndbroadbent]

Nice! I guess this might just be an issue with the new endsitter implementation, since the case you described isn't happening for the original vscode-endwise extension.

https://user-images.githubusercontent.com/139536/193366830-cebc3bfa-5d5e-4c18-8554-e07f1b2a00ef.mov

Would be kind of cool if it could detect this case though, and add a new line + move the cursor up.

@vfonic I'll try out your version today and see how it goes.