GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #346 received at 56682 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 29 Jul 2022 15:19:49 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, 56682-done <at> debbugs.gnu.org, larsi <at> gnus.org,
> monnier <at> iro.umontreal.ca
>
> > Hmm... I'm bothered by this code in handle_fontified_prop:
> >
> > if (it->narrowed_begv)
> > Fnarrow_to_region (make_fixnum (it->narrowed_begv),
> > make_fixnum (it->narrowed_zv), Qt);
> >
>
> Hmmm... that code has been on the branch for a week, and I didn't see
> particular bugs. Which doesn't mean there are none, of course.
It depends on what kind of bugs we expect. I've seen in a debugger
that fontification-functions are called with POS outside the narrowed
region. But since jit-lock simply does nothing in that case, this is
silently ignored.
> > This narrows the buffer around window's point position (since this is
> > how narrowed_begv and narrowed_zv are computed), but the display
> > iterator can be called for position outside this range. This is unlikely
> > to happen when the function is called as part of actual redisplay of a
> > window, but it can easily happen when the display code is used by other
> > primitives, for example vertical-motion or pos-visible-in-window-p.
> > What happens then is that fontification-functions are called with the
> > argument POS that is outside of the restriction, and that can cause
> > errors. (jit-lock simply does nothing in that case, AFAICT.)
> >
> > Is this intended?
>
> I'm not sure I understand how this could happen. Can a non-visible part
> of the buffer be fontified by fontification-functions when for example
> pos-visible-in-window-p is called and eventually returns nil?
Yes. Whenever the display code is called, it fontifies the portions
of the buffer that it moves through. And that is in general
justified: if we didn't fontify, we could produce wrong results from
pos-visible-in-window-p, due to faces that change the font height.
> At least if I do (pos-visible-in-window-p (point-max)), they are
> not: handle_fontified_prop is not even called with it at point-max.
> Even with (pos-visible-in-window-p (1+ (window-end)))
> fontification-functions are not called.
Try with vertical-motion. Visit long-line.xml, go to position 20000,
and then do "C-u 200 C-n" or "M-: (vertical-motion 200) RET. Sooner
or later you will see that it->current in handle_fontified_prop will
be outside of the narrowing.
> Should we perhaps be extra careful and add not apply the narrowing when
> IT_CHARPOS is not between narrowed_begv and narrowed_zv?
I'd rather narrow around IT_CHARPOS in that case. That would be also
consistent with what the doc string of fontification-functions now
says.
Perhaps we should also change what init_iterator does: if the start
position with which it's called is outside of the restriction,
recompute the restriction using the start point instead of the
window's point position. WDYT?
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.