GNU bug report logs - #21077
24.5; Slow printing in inferior python buffer with python-shell-enable-font-lock

Previous Next

Full log

Message #38 received at 21077 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ista Zahn <istazahn <at> gmail.com>
Cc: 21077 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#21077: 24.5; Slow printing in inferior python buffer with
 python-shell-enable-font-lock
Date: Fri, 31 Jul 2015 18:07:09 -0400

>> As mentioned, font-lock is but one of the parts of Emacs that slow down
>> as lines get longer.
> I'm not all that concerned with things slowing down slightly,

Neither am I.  All the others I care about also end up rendering
Emacs unusable.  They just show up at different times, or start biting
you at different line lengths.

>> In the case of comint modes, rather than disable font-lock we should
>> refrain from font-locking the text after the last \n (since that's the
>> line that keeps getting expanded, so we end up re-font-locking it O(N)
>> times for a line of length N, for a total amount of work of O(N^2)).
>> IIRC I have a similar hack in grep.el or compile.el.
> OK, but unless there are clear plans to fix this soon the default value of
> python-shell-enable-font-lock should be changed to nil until such time as a
> fix is in place.

I disagree.  All comint modes suffer from this problem, AFAIK, and
I don't see why Python programs would be more likely to generate long
lines than programs in other languages.

But yes, I'd really be happy to see some tentative patch along the lines
I outlined above.


        Stefan

Previous Next

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