GNU bug report logs -
#33959
26.1.90; python.el font-lock buffer wreaks havoc when company is enabled
Previous Next
Reported by: Carlos Pita <carlosjosepita <at> gmail.com>
Date: Thu, 3 Jan 2019 02:10:02 UTC
Severity: normal
Tags: fixed, patch
Found in version 26.1.90
Fixed in version 27.1
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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 <at> 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.
This bug report was last modified 5 years and 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.