[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company
From: |
Carlos Pita |
Subject: |
bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled |
Date: |
Tue, 16 Apr 2019 19:14:55 -0300 |
I'm unable to get your output, here the font lock buffer always
contains one line.
Nevertheless, I don't quite understand your example. Here:
In [14]: 1 + len('123') + 99 + len('aa')
In [14]: 1 + len('123') + 99 + len('aa')
Out[14]: 105
How do you manage to have two input lines with the same prompt number?
Is that an artifact of copy pasting from the REPL? If it is, if your
example just consists of successively sending the line `1 + len('123')
+ 99 + len('aa')` many times, I'm unable to reproduce the case (after
my patch is applied, that is, with this definition
(defun python-shell-font-lock-comint-output-filter-function (output)
"Clean up the font-lock buffer after any OUTPUT."
(unless (string= output "")
(if (let ((output (ansi-color-filter-apply output)))
(and (python-shell-comint-end-of-output-p output)
(not (string-match "\\.\\.\\." output))))
;; If output ends with an initial (not continuation) input prompt
;; then the font-lock buffer must be cleaned up.
(python-shell-font-lock-cleanup-buffer)
;; Otherwise just add a newline.
(python-shell-font-lock-with-font-lock-buffer
(goto-char (point-max))
(newline)))
output))
)
On Tue, Apr 16, 2019 at 7:08 PM Carlos Pita <carlosjosepita@gmail.com> wrote:
>
> > The above state happens after I've applied your patch #2.
>
> Ah, ok! I hadn't understood that was *after* applying the patch. Let
> me try to reproduce your example then.