bug#9470: 24.0.50; Possible bidi-related slowness

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  9470@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.