python: open brackets detector too impatient?

[pdknsk]

Write this.

y = list()

def x():
    return

Now delete the closing bracket of list(). Both def and return are immediately marked as errors. I think Sublime should perhaps not do this while the line is still being edited.

[FichteFoll]

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 with keyword, but it is impossible to detect when a function (or class) call is not closed because the user is still working on it.

However, an argument could be made for allowing statement keywords to appear in expression scopes (such as arguments) and not highlighting something like list(def) as invalid. Imo the current behavior helps spotting obvious errors and unclosed parentheses and ST's auto-matching behavior of parentheses should suffice with negating that downside.

[pdknsk]

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.

[FichteFoll]

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.

[pdknsk]

​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.

[pdknsk]

Or perhaps too verbose, rather than aggressive.

[pdknsk]

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.

[FichteFoll]

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]

Some possible bugs or quirks I noticed.

This works as expected, I think.

For some reason the reverse order is different.

I'm not sure about this.

[wbond]

@pdknsk I think the second example is working "properly" also. The with is invalid inside of [, and then as is invalid unless paired with something like with.

[FichteFoll]

The first is odd, because it seems to exit the scope at with instead of break. Third should break at def instead of : in the unbalanced parentheses.

I'll look into it.