Closed asterite closed 1 year ago
Okay, things are hooked up now but probably not in the best way (there's a bit of repetition and you have to remember to call fix_source
.)
In any case I can already showcase the improvements. Take a look at this:
It's autocompleting the x.
thing even though the source has a lot of missing end
s.
Or this:
It's showing the hierarchy at the top (Foo -> Bar -> foo) but the source is kind of broken.
Also "Go to definition" works fine in this state.
This is ready for review now. I've tried it with a bunch of files, removing "end" or curly braces, and it seems to be working fine.
One thing I noticed is that there weren't specs before so CI didn't run them. If we are going to have specs we might want to run them in CI.
This is ready for review now. I've tried it with a bunch of files, removing "end" or curly braces, and it seems to be working fine.
Sorry busy week I won't be able to review until this week end, but it is looking great from what I read so far ❤️.
One thing I noticed is that there weren't specs before so CI didn't run them. If we are going to have specs we might want to run them in CI.
True! I'll plug a github actions workflow for that.
This is for #55, but it's just a part of it.
This PR introduces a new type,
BrokenSourceFixer
. It tries to add missing "end" and closing curly braces based on the code's indentation. It assumes users will use two spaces of indentation and use the formatter so that everything is usually aligned except when they are typing an expression.The idea then would be to run this code before feeing it to the parser, if the source code is actually broken (for that we could try to parse it and if it parses fine then there's nothing to fix.)
I didn't hook up the code yet because I wasn't sure exactly where to do that.
Edit: another thing is that the fixer tries not to add new lines. In that way any code that needs parse locations will still work fine, as the fixer only adds to the end of lines.