emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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 

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.

  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:

  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 \


* 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).