-
Notifications
You must be signed in to change notification settings - Fork 586
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
python: open brackets detector too impatient? #500
Comments
There is no way to detect if you are "still editing a line" in syntax definitions. There are a couple tweaks that allow incomplete statements like a bare However, an argument could be made for allowing statement keywords to appear in expression scopes (such as arguments) and not highlighting something like |
I agree, there's definitely a positive side to it. That's why I put a question mark. Why not mark the opening bracket as an error, rather than basically the rest of the document? It'd still be very noticeable. |
It's not possible to know whether an opening brace does not have a closing one unless you parse the entire file. This is comparable to the halting problem. The syntax definition engine also does not support backtracking in this way for performance reasons. |
Hmm I still think the current warning is too aggressive basically. Also
it's not immediately clear that the missing closing bracket is the culprit.
|
Or perhaps too verbose, rather than aggressive.
|
I notice that in 3114 only the first keyword following an open bracket is affected (and less prominently), rather than the rest of the document. |
Hm, I guess we could exit a parens scope on the first keyword we find. That should reduce the amount of noise from illegally placed keywords due to a missing closing paren (or other bracket). |
@pdknsk I think the second example is working "properly" also. The |
The first is odd, because it seems to exit the scope at I'll look into it. |
Write this.
Now delete the closing bracket of
list()
. Bothdef
andreturn
are immediately marked as errors.I think Sublime should perhaps not do this while the line is still being edited.
The text was updated successfully, but these errors were encountered: