bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled

[Carlos Pita]

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.