[Top][All Lists]

[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]