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

Previous Next

Full log

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

From: Ista Zahn <istazahn <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Thu, 30 Jul 2015 20:27:15 -0400

[Message part 1 (text/plain, inline)]

On Jul 30, 2015 7:19 PM, "Stefan Monnier" <monnier <at> iro.umontreal.ca> wrote:
>
> > Sorry for the delay in responding. I think a reasonable short term
> > measure is to set python-shell-enable-font-lock to nil by default, and
> > perhaps add a warning to the doc string to the effect that setting it
> > to a non-nil value can dramatically slow down printing.
>
> As mentioned, font-lock is but one of the parts of Emacs that slow down
> as lines get longer.

python-shell-enable-font-lock is the only place I've encountered were
things become unusable. I'm not all that concerned with things slowing down
slightly, but I do think the cases (like this one) that render emacs
unusable need to be fixed or worked around.
>
> 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.

Best,
Ista
>
>
>         Stefan

[Message part 2 (text/html, inline)]

Previous Next

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