[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publish
From: |
Emily Bourke |
Subject: |
Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing |
Date: |
Wed, 06 Jan 2021 20:58:56 +0000 |
Thanks for the feedback!
> Nothing jumps out to me. For large files that are already visited, I
> suppose find-file-noselect returning an existing buffer can be faster,
> so relevant factors would include how many Org files a project has, how
> large they are, and how many of those are visited in the current
> session. My guess is that using with-temp-buffer and
> insert-file-contents would be a net gain, though that gain would be
> narrowed some if the temporary buffer was put into org-mode rather than
> kept in fundamental-mode (more below).
I'll do some testing with some large org files and see how things compare – it
might be worth switching to the buffer for the file if there is one already.
> This reads to me like after-find-file is the hook itself. Perhaps
> something like this would be clearer: "... avoids calling
> after-find-file and running find-file-hook, ...".
Ah yes, I had misunderstood – I'll rephrase it.
> The goto-char call can be dropped now because insert-file-contents inserts
> after point.
I follow, will remove.
> Unlike the previous code, this doesn't activate org-mode in the buffer.
> That gives a speedup. And I don't spot any code downstream that depends
> on the major mode being org-mode, so it's probably safe, though perhaps
> there's a subtle change in behavior here (e.g., related to syntax
> table).
>
> If org-mode isn't called, the org-inhibit-startup binding above could be
> dropped.
Yeah, if you're worried about it I could try manually activating org mode in
the temp buffer – I'm not confident I could predict any problems there might be
from not activating it.
> This introduces a regression. With the previous code, the
> find-file-noselect call led to default-directory being set to the Org
> file's directory, and then this expand-file call on the included file
> was relative to that. With the new code, default-directory isn't
> changed, so it points to a non-existing or incorrect file unless the
> current default-directory and the Org file's happen to match.
Ah, I hadn't noticed this – I'll change it to set default-directory manually.