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

Previous Next

Full log

View this message in rfc822 format

From: Noam Postavsky <npostavs <at> gmail.com>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 33959 <at> debbugs.gnu.org
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

Carlos Pita <carlosjosepita <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.