From: Max Nikulin <email@example.com>
To: Greg Minshall <firstname.lastname@example.org>, Org Mode <email@example.com>
Subject: Re: tangle option to not write a file with same contents?
Date: Sat, 7 May 2022 15:05:14 +0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
A couple additional notes for the case that someone will find this
thread in future.
On 28/10/2021 11:04, Greg Minshall wrote:
> i wonder if it would be reasonable to add an option such that, when
> tangling, `org-babel-tangle` would not write a file with the
> already-existing contents of the target file?
> this would be helpful, e.g., for those of us who use make(1)-based work
It was not obvious for me earlier that it should be namely an *option*,
not just change of behavior, since e.g. `org-babel-load-file' relies on
timestamp comparison of the source .org file and the derived .el file. I
am unsure concerning default value of such setting.
It was an issue with `org-file-newer-than-p' that reminded me about this
P.S. Timestamp comparison is not always reliable to determine whether
prerequisite has not been updated. Earlier python had timestamp of .py
file saved in the header of compiled .pyc files, but at some moment they
switched to hash.
PEP 552 – Deterministic pycs
next prev parent reply other threads:[~2022-05-07 8:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-28 4:04 tangle option to not write a file with same contents? Greg Minshall
2021-10-29 16:21 ` Max Nikulin
2021-10-29 17:58 ` Greg Minshall
2021-10-30 15:13 ` Max Nikulin
2021-10-30 16:13 ` Greg Minshall
2022-05-07 8:05 ` Max Nikulin [this message]
2022-05-08 4:42 ` [PATCH] " Ihor Radchenko
2022-05-17 15:39 ` Max Nikulin
2022-05-30 3:14 ` Ihor Radchenko
2022-05-31 16:07 ` Max Nikulin
2022-06-03 7:04 ` Ihor Radchenko
2022-06-07 3:47 ` Tom Gillespie
2022-06-01 13:18 ` Greg Minshall
2022-09-12 17:36 ` Org version mismatch -- hooray! Greg Minshall
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).