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

[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?





reply via email to

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