]> git.eshelyaron.com Git - emacs.git/commit
Fix python-shell font-lock cleanup for unclosed quotes (Bug#32390)
authorCarlos Pita <carlosjosepita@gmail.com>
Tue, 4 Dec 2018 22:35:09 +0000 (19:35 -0300)
committerNoam Postavsky <npostavs@gmail.com>
Tue, 15 Oct 2019 00:09:38 +0000 (20:09 -0400)
commit7acc621e373ba1371495e15e5e78aa6ce948a9a6
treeb15ec2bbfa4143d1097815c5f047940715453a1e
parent8a089a95d8dc5a3b579a349785793dd52ecdb7cd
Fix python-shell font-lock cleanup for unclosed quotes (Bug#32390)

The problem originating this report was:

-------------
In [15]: "
  File "<ipython-input-15-3b7a06bb1102>", line 1
    "
     ^
SyntaxError: EOL while scanning string literal

In [16]:   string face still here"
-------------

This happens because
python-shell-font-lock-comint-output-filter-function is called twice,
first for the error output and then for the "In [16]: " part.  The
first time python-shell-comint-end-of-output-p returns nil since
we're *not* at the end of an input prompt.  The second time it returns
0 since we're at the end of *just* an input prompt.  So we don't call
python-shell-font-lock-cleanup-buffer either time.

The current code is relying in a very weak rule: it considers "just an
input prompt" to be a continuation prompt.  Another unreliable aspect
of the current rule is that sometimes

    (python-shell-comint-end-of-output-p (ansi-color-filter-apply output))

returns 1 and not 0 for continuation prompts.  In short, the rule does
a very poor job identifying continuations.

* lisp/progmodes/python.el (python-shell-font-lock-cleanup-buffer):
Don't check for empty OUTPUT since python-shell-comint-end-of-output-p
returns nil for that anyway.  Don't check for
python-shell-comint-end-of-output-p returning a specific number
because it's unreliable, just check for any non-nil.  Identify
continuation prompts by looking for "...".
lisp/progmodes/python.el