From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: tangle option to not write a file with same contents?
Date: Sat, 30 Oct 2021 22:13:20 +0700 [thread overview]
Message-ID: <sljnej$v9f$1@ciao.gmane.io> (raw)
In-Reply-To: <860561.1635530303@apollo2.minshall.org>
On 30/10/2021 00:58, Greg Minshall wrote:
>
>> Some hash-based build systems are mentioned in that thread. Since that
>> time more more similar tools have appeared, e.g. buck,
>> reimplementations of DJB's redo https://cr.yp.to/redo.html
>
> i think different people will settle on different build tools.
Greg, I see your point and often I am not happy to change established
workflow as well. Partially a reason is that it requires some efforts.
This particular issue should be handled in Org code. (Unfortunately it
requires some efforts as well.) On the other hand, it may be treated in
a more general way by external hash&cache build tool.
Actually I have no suggestion concerning particular build system. E.g.
buck is too heavy (python+java), and my experience is not purely positive.
>> It seems `compare-buffer-substrings` has more logic than just byte to
>> byte comparison. Is it to handle alternatives for unicode character
>> alternatives? For tangled buffer it should be size that is checked
>> first...
>
> you are right, it definitely makes sense to look first at size. (which
> is what, e.g., rsync(1) does.) also, probably i needn't have mentioned
> `compare-buffer-substrings` -- i was really just trying to suggest
> "simple" (which maybe i anti-did?).
I think, `compare-buffer-substrings' is a good starting point. It is
ready to use and I am not aware of obvious problems with it. (Can it
happen that change of file encoding would be discarded since buffers are
equal?) I just was curious whether the function performs size check. It
does, but comparison is not identity test, so it is at the end of the
function.
In the meanwhile I realized that check for modification by user should
be performed *before* tangle, and hash to detect changes is appropriate
for such purpose. I think, a copy of tangled file just to detect
modification will cause some tension from users.
Comparison of earlier and current tangle results should be done at the
end, so implementation should be independent. There is no point to use
hash, size + byte to byte comparison is fast and reliable.
A subtle point partially discussed earlier is overwriting content of
existing file vs. tangling to temporary file and atomic replacement. In
most cases the latter is preferred. However if target file is open for
debugging in an editor, content should be written to the existing file
(preserving inode). It allows to preserve unsaved changes if the editor
notifies user that file is modified.
next prev parent reply other threads:[~2021-10-30 15:14 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 [this message]
2021-10-30 16:13 ` Greg Minshall
2022-05-07 8:05 ` Max Nikulin
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
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='sljnej$v9f$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).