[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: |
Noam Postavsky |
Subject: |
bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled |
Date: |
Tue, 16 Apr 2019 19:01:35 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
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.