bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: Fix the long lines font locking related slowdowns


From: Gregory Heytings
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 01 Aug 2022 12:51:47 +0000



You can see in the sources that both init_iterator and start_display are many times called with 'struct it' that was used by the caller, so it could already have the narrowed_begv and narrowed_zv members initialized by the caller. If we discover that we want to recalculate these values, we'd then need to restore the previous value before we return, so that the caller will see the same values it used before the call. But we have no easy way of doing that, and moreover, cannot even detect that these members were initialized. The inability to detect that they were initialized is due to the fact that we don't initialize 'struct it' before we call init_iterator, and so these fields can originally have any arbitrary value.


Thanks, it's much clearer now.


Which means, for example, that tests like this:

 if (current_buffer->long_line_optimizations_p)
   {
     if (!it->narrowed_begv  <<<<<<<<<<<<<<<<<<<<<<<<<<
        || ((pos.charpos < it->narrowed_begv || pos.charpos > it->narrowed_zv)
            && (!redisplaying_p || it->line_wrap == TRUNCATE)))

are not necessarily reliable, because we never initialize narrowed_begv to zero, AFAICT. Right?


Indeed. That wasn't a problem with the previous code in which narrowed_begv was unconditionally assigned. Now it is. I think the following change should be enough to fix this. Agreed?

diff --git a/src/xdisp.c b/src/xdisp.c
index 8a19b3bda9..9574d06bd5 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -3472,6 +3472,9 @@ init_iterator (struct it *it, struct window *w,
                        &it->bidi_it);
        }

+      if (current_buffer->long_line_optimizations_p)
+       it->narrowed_begv = 0;
+
       /* Compute faces etc.  */
       reseat (it, it->current.pos, true);
     }


The other part of my reasoning is that callers of the display code which are outside redisplay could legitimately move the iterator far from point: think about pos-visible-in-window-p and its ilk. So, when we are not called by redisplay, I think it would be preferable to update the narrowing due to these considerations.


Thanks, this too clarifies what you meant.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]