Terry J. Reedy <tjre...@udel.edu> added the comment:
For me, on Mac, only the 3rd 'def', on line 4, changes to blue, the default highlight for defined names (those immediately following 'def' or 'class'). This is because deleting the '#' causes recoloring from there onward, and IDLE's handling of newlines after 'def' or 'class' is buggy. I presume that you see the same. I most concerned with correctly highlighting correct code. It may be ambiguous what to do with incorrect code. If one types 'def name' or 'class name' to start a line, name is colored blue as a definition name. If name happens to be misspelled to match a keyword, should it be colored as a keyword? Maybe, but in this context, it will not function as such. Perhaps it should be immediately colored as a syntax error (default red), instead of waiting for an explicit syntax check. But this an innovation for IDLE and should be a different issue from this one. If there is a newline between def/class and the name, python sees it as a space if escaped with '\' but a syntax error if not. IDLE effectively does the opposite. The idprog in idlelib.colorizer uses \s, which matches a bare newline, among other things, but not 'backslash newline'. I intend to replace '\s' with alternatives legal in this context. def\ name ... # Name should be blue, at least after multiline recolor. def name ... # 'def\n' is error; name should not be blue ever. ---------- stage: -> needs patch title: IDLE: Undesired highlight -> IDLE: Wrong highlighting when \n follows def/class versions: +Python 3.7, Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40384> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
