unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Chong Yidong <cyd@gnu.org>
Cc: 10835@debbugs.gnu.org
Subject: bug#10835: 24.0.93; bidi-paragraph-direction slows down Shell mode
Date: Sat, 18 Feb 2012 10:49:19 +0200	[thread overview]
Message-ID: <83y5s0v84w.fsf@gnu.org> (raw)
In-Reply-To: <87y5s0dd6q.fsf@gnu.org>

> From: Chong Yidong <cyd@gnu.org>
> Cc: 10835@debbugs.gnu.org
> Date: Sat, 18 Feb 2012 11:37:33 +0800
> 
> Chong Yidong <cyd@gnu.org> writes:
> 
> > I just noticed that when I do `ls --color=no' rather than just `ls',
> > insertion and scrolling are very fast.  The sluggishness only appears
> > when ls color highlighting is enabled.  So the inefficiency of
> > ansi-color.el, and its use of overlays, seems to play a role.
> 
> I just confirmed that the sluggishness goes away if I change
> ansi-color.el to make it use text properties.

That figures.  bidi.c needs to look up display properties and overlays
with display strings, in order to DTRT with their display (they are
treated as a single neutral character).  So having lots of overlays
slows down redisplay a bit more.

> Wish I'd remembered to do that before the pretest began.

If this is a grave problem, we can still do it now, I think.  Or we
could use a band-aid, see below.

> Roughly what is happening, I think, is that when overlays are heavily
> used and there are no paragraph breaks (e.g. from the `time' output),
> the bidi code does enough the additional overlay lookups to produce a
> noticeable slowdown.

Yes, the overlays together with the long search for paragraph
beginning probably push the user experience from slightly below the
annoyance threshold to just above it.

> I'm not sure what's the best fix right now, though.

How about setting bidi-paragraph-direction in comint buffers to
left-to-right when the locale indicates that use of bidirectional
scripts is unlikely?  We could use locale-language-names and an
additional small database of languages that need bidi, to make that
decision.  WDYT?





  reply	other threads:[~2012-02-18  8:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-17  5:41 bug#10835: 24.0.93; bidi-paragraph-direction slows down Shell mode Chong Yidong
2012-02-17  5:48 ` Chong Yidong
2012-02-17  8:21   ` Andreas Schwab
2012-02-17 13:42     ` Chong Yidong
2012-02-17 16:08   ` Eli Zaretskii
2012-02-17 17:39     ` Chong Yidong
2012-02-17 18:27       ` Eli Zaretskii
2012-02-18  2:28         ` Chong Yidong
2012-02-18  3:37           ` Chong Yidong
2012-02-18  8:49             ` Eli Zaretskii [this message]
2012-02-18 14:14               ` Eli Zaretskii
2012-02-19 14:07               ` Chong Yidong
2012-02-18  8:27           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y5s0v84w.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=10835@debbugs.gnu.org \
    --cc=cyd@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).