GNU bug report logs - #10835
24.0.93; bidi-paragraph-direction slows down Shell mode

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 10835 <at> debbugs.gnu.org
Subject: Re: bug#10835: 24.0.93; bidi-paragraph-direction slows down Shell mode
Date: Sat, 18 Feb 2012 10:27:18 +0200

> From: Chong Yidong <cyd <at> gnu.org>
> Cc: 10835 <at> debbugs.gnu.org
> Date: Sat, 18 Feb 2012 10:28:12 +0800
> 
> Times are below.  Another observation: with `time ls /usr/share/doc'
> (which does use color highlighting), scrolling through the Shell buffer
> is no longer sluggish.  I think the output of `time' helps by providing
> a paragraph break.

Of course.  That makes each 2000-line output a separate paragraph, as
far as bidi is concerned.  So you never get to the 7500-line limit of
searching for paragraph beginning.

When I tried to reproduce the problem on Windows, I manually edited
away these empty lines (which are inserted in my case because the
shell prompt on Windows always starts with a newline).

> If I do plain `ls' (no `time'), then go back and edit the Shell buffer
> manually by adding a C-q C-j line break after each prompt, that also
> makes the scrolling sluggishness go away.

Of course, for the same reasons.

> In the Emacs 24 shell buffer, after 10 invocations:
> 
> real	0m1.969s
> user	0m0.008s
> sys	0m0.004s

Is this with the empty lines between invocations, or without?

If the former, do the 2 seconds match your impression of sluggishness,
i.e., do you indeed see Emacs take about 2 sec to insert the 10th
listing into the shell buffer?  Or does the insertion take much
longer?  (Timing with second-resolution can be done by just looking at
your wallclock time.)

Previous Next

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