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: Fri, 29 Oct 2021 23:21:52 +0700	[thread overview]
Message-ID: <slh732$h5t$1@ciao.gmane.io> (raw)
In-Reply-To: <583051.1635393898@apollo2.minshall.org>

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?

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.

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

  reply	other threads:[~2021-10-29 16:24 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 [this message]
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
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='slh732$h5t$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).