[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tangle option to not write a file with same contents?
From: |
Max Nikulin |
Subject: |
Re: tangle option to not write a file with same contents? |
Date: |
Fri, 29 Oct 2021 23:21:52 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
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?
Are you going to celebrate a decade of the feature request?
https://list.orgmode.org/orgmode/CAFDswJtMzFZgRQqsFtiQNT7c1uFE7HV4kek5j9akx1yAdWZZEg@mail.gmail.com/T/#u
Holger Hoefling @ 2011-11-18 13:17 UTC
Not overwriting unchanged source code files when tangling
this would be helpful, e.g., for those of us who use make(1)-based work
flows.
I agree with you, make is wide spread and fast tool that is really
convenient in simple cases.
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
then, if this might generally be thought useful, i wonder if this should
be implemented as specifically this, or whether we might implement a
callback at the appropriate point in `org-babel-tangle` asking whether
or not to proceed. (then, the user's callback routine could do the
comparison.)
if we do "specifically this", i would suggest that this comparison be
dead simple: read in the existing file's contents into some hidden
buffer, and use `compare-buffer-substrings` to compare point-{min,max}
of both.
Tom Gillespie mentioned that it is easy to lost modifications of tangled
files created during debugging.
https://list.orgmode.org/orgmode/CA+G3_PNo8i8U9rOrC8BBydjEv9=LKgtJBopwX9J6vyNXdnjtXg@mail.gmail.com/T/#u
I think, some header may be added to tangled file containing hash of
rest part of file. So the file may be checked for user modifications
before overwriting, that hash may be compared with the new buffer to
keep existing file in place.
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...