[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal: Change publication timestamps (was: Publishing cache)
From: |
Jens Lechtenboerger |
Subject: |
Proposal: Change publication timestamps (was: Publishing cache) |
Date: |
Mon, 12 Aug 2024 09:55:55 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
On 2024-06-14, Ihor Radchenko wrote:
> Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
>
>> Jumping in here, I do not understand the publishing cache. Some of
>> my org documents are re-published every time, while others are only
>> re-published after changes. What is checked where?
>
> See "14.4 Triggering Publication" section of Org mode manual:
>
> Org uses timestamps to track when a file has changed. The above
> functions normally only publish changed files. You can override this
> [...]
I propose to change caching and checking of timestamps as in the
attached path.
Currently, org-publish-cache-file-needs-publishing checks whether
the source file was modified after the cached modification time,
which is fine. However, for each included file B, it checks whether
that was modified more recently than the source file A. If so, the
source is file A is considered to need publishing. This does not
make sense. File A will be published again and again, even if
neither A nor B changed since the last publishing.
In the patch, I store the current time in the publish cache, not the
source file’s modification time. Also, for included files, I do not
check their timestamp against the one of the source file but against
the cached publish timestamp.
What do you think?
As an aside, recursive inclusions are currently not checked.
Maybe code to collect all included files is available elsewhere in
the code base?
Also, in my case, it would be useful to have a new keyword like
“#+PUBLISH_DEPENDENCY: some-file” to record timestamps for
additional dependencies, whose changes should also trigger
publishing. Currently, that could be added as alternative to the
regexp for INCLUDE. However, maybe you prefer to refactor that
code to deal with recursive inclusions?
Best wishes,
Jens
0001-lisp-ox-publish.el-Use-publish-time-in-publish-cache.patch
Description: Text Data
smime.p7s
Description: S/MIME cryptographic signature
- Proposal: Change publication timestamps (was: Publishing cache),
Jens Lechtenboerger <=