-
Notifications
You must be signed in to change notification settings - Fork 225
Make on type formatting end completions more robust
#779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
egiurleo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! This implementation is much simpler!
bitwise-aiden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Excited to try this out :D
|
Actually, do we have a way to check if an end already exists for this code block? One thing I've noticed is additional ends in cases where I edit the opening line and hit enter. |
…e bundle (#779) * Make tests pass locally * Fix debugger launch configurations when `debug` is not included in the bundle
Motivation
Closes #500
This bug was bothering me too much. Instead of trying to use the document scanner, I switched the implementation of the on type formatting
endcompletions to just deal with document lines. This simplifies the implementation and makes it easier to address the bug, so I think it's a win-win.Implementation
The way the lines work are as follows
So, the final logic is:
endtoken normallyendtoken in a way that allowssomethingto be in betweenAutomated Tests
Added a scenario and fixed another one that was weird.
Manual Tests
Basically fire up the LSP on this branch and play around breaking
ifstatements. See if theendtoken ends up weird in any combination.