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

Previous Next

Full log

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

From: Rasmus <rasmus <at> gmx.us>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 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

Previous Next

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