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: Rasmus <rasmus <at> gmx.us>
To: 21077 <at> debbugs.gnu.org
Subject: bug#21077: 24.5; Slow printing in inferior python buffer with python-shell-enable-font-lock
Date: Fri, 17 Jul 2015 10:56:05 +0200
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> It wasn't.  Something is clearly wrong with the regexps involved in
>> this recipe, at least.
>
> The trigger is simple and a well-known problem in Emacs: the command you
> pass to Python outputs one very long line, and Emacs assumes at various places
> that lines aren't too long.  One such assumption is in font-lock itself,
> another appears to be in one of the regexps used in the font-lock config
> of inferior python mode.

The problem is also very much present in the R interface provided by ESS.

The R package data.table has a pretty good solution to long output IMO.
E.g.

R> data.table(x=1:1000000)
                x
       1:       1
       2:       2
       3:       3
       4:       4
       5:       5
      ---        
  999996:  999996
  999997:  999997
  999998:  999998
  999999:  999999
 1000000: 1000000

As I remember Python Pandas does something similar.

Would it be feasible to implement a generalized version of cutting output
for comint-like output if exceeding N lines?

Rasmus

-- 
Warning: Everything saved will be lost





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.