[Python] Bug in Closing Quotes in Python Comments

### What happened? cc: @deathaxe Hi, DeathAxe! I am CC-ing you because I traced down the problem part way and did a "blame" report on the offending file and discovered you might have been involved with the key-binding that is causing the problem. Here are the steps I went through thus far: I noticed that while in Python comments (not true for any other language), after typing: ``` "any string|" ^ +--caret here ``` that when I then type a `"` (double-quotation mark), that instead of executing `"command": "move", "args": {"by": "characters", "forward": true}`, it inserts a new double-quotation mark, leaving me with this: ``` "any string"|" ^ +--caret here ``` The problem does not occur in Python code, or anywhere else that I could tell—just in Python comments. (The scope in a Python comment is "source.python comment.block.documentation.python" throughout the comment.) So I put this in my `User/Default (Windows).sublime-keymap`, which is a copy/paste of the key binding for closing double-quotes from `Packages/Default/Default (Windows).sublime-keymap`, except I commented out the line shown below: ```jsx // ==================================================================== // Experimental // ==================================================================== // -------------------------------------------------------------------- // Hypotheses: In Python comments, the closing single- and double-quotes // does not function correctly (by moving the cursor forward instead of // inserting a closing quotation mark), because of the `selector` // context key. // -------------------------------------------------------------------- { "keys": ["\""], "command": "move", "args": {"by": "characters", "forward": true}, "context": [ { "key": "setting.auto_match_enabled", "operator": "equal", "operand": true }, { "key": "selection_empty", "operator": "equal", "operand": true, "match_all": true }, { "key": "following_text", "operator": "regex_contains", "operand": "^\"", "match_all": true }, // { "key": "selector", "operator": "not_equal", "operand": "punctuation.definition.string.begin", "match_all": true }, { "key": "eol_selector", "operator": "not_equal", "operand": "string.quoted.double - punctuation.definition.string.end", "match_all": true }, ] }, ``` At which point the problem "seemed" to clear up except now did a "move forward by 1 character" with beginning quotes, which wasn't going to work. So I uncommented that line again, and to my surprise, the problem STILL WAS NO LONGER HAPPENING! So I realized that there was an "intervening" keymap somewhere. And I traced it down to the first key-binding entry in the `Python/Default.sublime-keymap` file. ALSO: I tried copying a modified version of Python key-binding entry into my `User/Default (Windows).sublime-keymap` file and it seems to "patch" the problem. ```jsx { "keys": ["\""], "command": "insert", "args": {"characters": "\""}, "context": [ { "key": "setting.auto_match_enabled" }, { "key": "selector", "operand": "source.python - string.quoted.double" }, { "key": "selector", "operand": "source.python comment", "operator": "not_equal"}, // <-- additional condition { "key": "selection_empty", "match_all": true } ] }, ``` What still don't understand though is what problem that key binding solves, because without it, the behavior of the closing double-quotes seems to work nicely everywhere thus far I have tested it. I'm going to leave that key binding (and the same one for closing single quotes) in my `User/Default (Windows).sublime-keymap` for now, as now it seems to be well-behaved everywhere now. I will test it for a few days and see if this remains true.