GNU bug report logs - #9470
24.0.50; Possible bidi-related slowness

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9470 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#9470: 24.0.50; Possible bidi-related slowness
Date: Sun, 11 Sep 2011 02:25:59 -0400

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org,  9470 <at> debbugs.gnu.org
> Date: Sun, 11 Sep 2011 01:18:17 -0400
> 
> I'd guess that a cache that stores (START . END) could help, where
> "START is a position that starts a paragraph and that paragraph ends no
> sooner than END".
> 
> This way when working within a very long paragraph, you only need to
> look for a paragraph boundary between END and point and if there isn't
> any, you can go straight to START without searching for it.

I'm not sure I'm following.  Are you assuming that redisplay is
entered immediately after each deletion or insertion, and therefore
these edits are always at point?  Because that assumption is false,
AFAIK: Emacs could perform any number of edits before reentering
redisplay, so changes could be at places that are not at point and not
even in the visible portion of the buffer.  Any of these edits could
insert or delete a paragraph boundary, and thus potentially change the
paragraph direction.

If you don't assume changes at point, then I don't see how point is
relevant to this issue.  Am I missing something?

There are other complications with your proposal, e.g. the need to
look for and keep track of paragraph end, which I currently don't care
about, and the need to recompute the values of START and END when
point moves far way.  But the above is the major one.

Previous Next

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