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 22:49:23 -0400
> 
> I do assume we have some way to flush the cache (or parts thereof)
> that become invalid, tho.

If we add the necessary code to prepare_to_modify_buffer, yes.  That
code will need to either update the START and END positions or
invalidate the cache, depending on what modification is about to
happen.  But not if the change is to add or remove text properties.
We will also need to invalidate the cache whenever the iterator
position winds up outside the (START..END) region, and update it as we
cross paragraph boundaries during iteration.  And that's just result
of 5 minutes of thinking and zero testing.

> > Any of these edits could insert or delete a paragraph boundary, and
> > thus potentially change the paragraph direction.
> 
> Sure.  But if there aren't any edits, the cache is still valid.

If there are no edits _and_ point didn't move before START or far
after END.

> I'm sure there are complications and that it won't remove
> all slowdowns.  But it should help the case in point (movement in
> a very long paragraph) by only suffering the slow "find paragraph
> beginning" once rather than for every command.

Having the first command take 5 seconds is still going to annoy.  We
must get it below 0.5 sec to make it acceptable.  And commands that
will invalidate the cache and cause slow display and unresponsive
Emacs are still a plenty.  So this cannot be the whole solution.  And
the logic described above is not trivial.

So for Emacs 24.1, I would go with a simpler solution which will solve
all the use cases, probably 90+ percent of them correctly: if a
paragraph boundary is not found after searching for a while, go to
point-min.  I will try to code it soon and see if this works well
enough.