GNU bug report logs -
#53749
29.0.50; [PATCH] Xref backend for TeX buffers
Previous Next
Reported by: David Fussner <dfussner <at> googlemail.com>
Date: Thu, 3 Feb 2022 15:10:02 UTC
Severity: normal
Tags: patch
Found in version 29.0.50
Fixed in version 31.1
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Thank you, Dmitry! I'll run tests later today and get back to you.
David.
On Thu, 9 May 2024, 04:00 Dmitry Gutov, <dgutov <at> yandex.ru> wrote:
> On 07/05/2024 05:27, Dmitry Gutov wrote:
> > On 03/05/2024 16:42, Stefan Monnier via Bug reports for GNU Emacs, the
> > Swiss army knife of text editors wrote:
> >>> Thanks for looking over the patch. Here's the recipe for the purported
> >>> bug in xref.el:
> >> The problem stems from xref.el's constant abuse of
> >> `inhibit-modification-hooks`. Binding this var to t should be done only
> >> in exceptional circumstances and should ideally be accompanied by a
> >> comment explaining why it's necessary.
> >
> > Well, the reason is performance: I've tried to wring out the most out of
> > it, given that we have to parse the buffer for syntax in Elisp, and
> > that'll always have a certain overhead.
> >
> > The difference between inhibiting and not could be up to 20% of runtime.
> >
> > David's fix makes things slower (just due to having us do the necessary
> > work), but still has an edge over having no inhibit-modification-hooks.
> >
> > That remaining improvement is around 4-7% in my testing, though, so
> > maybe it's the point where we should prioritize simplicity.
>
> For now, I've pushed a fix in 86187d43e2d which seems to handle David's
> scenario and address your review comment as well.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 243 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.