gh-140334: Fix IDLE syntax highlighting after line continuations - #140335
TheLizzard wants to merge 6 commits into
Conversation
There was a problem hiding this comment.
I can confirm the fix works on Linux:
But during typing that I noticed that the keyword pattern also suffers from this issue:
I think this regex approach is getting very messy, the builtin get's quite a bit more complex. I assume that brings significant performance penalties. At a minium I would suggest refactoring some things, rather than having to explain the lookahead each time move it to some constant e.g. LAST_LINE_NO_CONTINUATION. At best I think we could possibly try an reuse the new repl's logic, which uses tokens at not such excessive regexs.
| @@ -17,6 +17,7 @@ def any(name, alternates): | |||
| def make_pat(): | |||
| kw = r"\b" + any("KEYWORD", keyword.kwlist) + r"\b" | |||
There was a problem hiding this comment.
This pattern also suffers from the issue.
There was a problem hiding this comment.
Since the code str.for will always raise a SyntaxError, colouring in the for like a keyword will help beginners recognise that keywords are reserved and cannot be used as variable names/attributes. I believe that the keyword pattern is working correctly. I updated the match/case patterns since they are soft keywords and are valid variable/attribute names.
…Hm.rst Made by @StanFromIreland Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
|
Please do not use the Update Branch button unless necessary (e.g. fixing conflicts, jogging the CI, or very old PRs) as it uses valuable resources. For more information see the devguide. |
|
I did some profiling and here are my results:
I think that re-writing it with |
|
This PR is stale because it has been open for 30 days with no activity. |
The lazy soft keyword added in pythonGH-142351 gets the same continuation-line guard as the other soft keywords.
serhiy-storchaka
left a comment
There was a problem hiding this comment.
The approach is sound; I verified the cases from the issue and the tests with a display. Two changes and one note:
- The
builtinpattern guards against starting inside indentation with(?<!\.| ), a space only. With tab indentation the match can start at the second tab, past the backslash check, soself.\+ newline +\t\tsetcolorssetas a builtin again. Use(?<![. \t])— the tests still pass with it. - "slash" → "backslash" in the comments and the NEWS entry.
- A comment ending with a backslash suppresses a soft keyword on the next line (
# see \+ newline +match x:). Acceptable for a regex-based colorizer; the tokenizer-based one (gh-140347) would fix it.
I merged main to resolve the conflict with the lazy soft keyword from PEP 810; it now gets the same continuation guard as match and case.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Description
This PR fixes incorrect syntax highlighting in IDLE when a line ends with a backslash (
\) used for line continuation.Previously
Identifiers following a backslash were sometimes misinterpreted as keywords or built-ins instead of variables or attributes.
For example in:
The last
matchwas coloured like a keyword instead of a variable.Summary of changes
Fixes gh-140334