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

Previous Next

Package: emacs;

Reported by: Ista Zahn <istazahn <at> gmail.com>

Date: Thu, 16 Jul 2015 17:06:02 UTC

Severity: minor

Tags: fixed

Found in version 24.5

Fixed in version 25.1

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Wolfgang Jenkner <wjenkner <at> inode.at>
Cc: 21077 <at> debbugs.gnu.org, Ista Zahn <istazahn <at> gmail.com>
Subject: bug#21077: 24.5; Slow printing in inferior python buffer with python-shell-enable-font-lock
Date: Mon, 03 Aug 2015 17:41:24 -0400
>> 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.

> But comint-output-filter does

> (font-lock-prepend-text-property prompt-start (point)
> 					       'font-lock-face
> 					       'comint-highlight-prompt)

> So keyword fontification seems to be inhibited anyway.  Is this done in
> a particularly inefficient way?

That doesn't inhibit keyword fontification per se.  It just makes most
keyword rules ineffective, but the test is done after the hard work
anyway, so in a way yes, it's done in an inefficient way (tho skipping
some keywords by checking font-lock-face would in general be
even more inefficient).


        Stefan




This bug report was last modified 8 years and 316 days ago.

Previous Next


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