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

[Noam Postavsky <npostavs@gmail.com>]

Carlos Pita <carlosjosepita@gmail.com> writes:

> I'm unable to get your output, here the font lock buffer always
> contains one line.

Hmm, it might have to do with the fact that I'm running ipython over
TRAMP, since my main box doesn't have IPython 6.x.  But I suspect that
only affects the timing, so that it's still theoretically possible
(although less likely) for it to happen when running locally.

> 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?

I don't know, I didn't realize it was abnormal.  As far as I can tell,
the prompt number increases by a random amount (sometimes 0) each time I
press enter.

> Is that an artifact of copy pasting from the REPL?

No, that's the real text of my *Python* buffer, unedited.

> 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

My example consists of successively *typing* the line "1 + len('123') +
 99 + len('aa')", it usually takes about 3 tries before I see trouble.