[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.
- bug#56682: Fix the long lines font locking related slowdowns, (continued)
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/03
bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns,
Gregory Heytings <=
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/01
bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/01