[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58860: 29.0.50; [PATCH] semantic/fw.el: speed up the 'semantic-find-
From: |
Eli Zaretskii |
Subject: |
bug#58860: 29.0.50; [PATCH] semantic/fw.el: speed up the 'semantic-find-file-noselect' |
Date: |
Sun, 30 Oct 2022 08:56:40 +0200 |
> Cc: 58860@debbugs.gnu.org
> Date: Sat, 29 Oct 2022 11:06:29 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> > I find the semantic mode will try to analyse the chained header files,
> > by calling the function (semantic-find-file-noselect ...) to open the
> > file and analyse its content, while the `find-file-hook` may have many
> > heavy functions.
> > Disabling the `find-file-hook` do have great performance improvement
> > for semantic mode.
>
> Putting expensive code in `find-file-hook` is usually a problem
> in itself. And like Eli, I find it risky to disable it wholesale.
>
> But the rest of code seems to call this function only if the file is not
> yet visited and it always tries to kill the buffer afterwards, so really
> this could just as well use a temp buffer and
> `insert-file-contents` instead.
>
> So in the end I guess the patch is OK (except for the comment, which
> just paraphrases the code and thus doesn't add any information).
> The other disabled thingies in that function are already similarly
> problematic :-)
It all made sense to me, until the last paragraph: it seems to
contradict the other two? You say that disabling find-file-hook is
dangerous, and that the code in question could have used
insert-file-contents into a temporary buffer, in which case
find-file-hook would not come into play. So I assumed you'd suggest
to rewrite that function to use a temporary buffer. Instead, you say
that the patch is fine?.. What did I miss?