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.