From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id SB2zI2NhfWGVLwEAgWs5BA (envelope-from ) for ; Sat, 30 Oct 2021 17:14:43 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id cCM+H2NhfWHtdgAAbx9fmQ (envelope-from ) for ; Sat, 30 Oct 2021 15:14:43 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id ED122B292 for ; Sat, 30 Oct 2021 17:14:42 +0200 (CEST) Received: from localhost ([::1]:38756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgq4A-0005Qf-6z for larch@yhetil.org; Sat, 30 Oct 2021 11:14:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgq35-0005QG-Fo for emacs-orgmode@gnu.org; Sat, 30 Oct 2021 11:13:35 -0400 Received: from ciao.gmane.io ([116.202.254.214]:35894) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgq33-0006vD-4B for emacs-orgmode@gnu.org; Sat, 30 Oct 2021 11:13:35 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mgq31-0008YR-0J for emacs-orgmode@gnu.org; Sat, 30 Oct 2021 17:13:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: tangle option to not write a file with same contents? Date: Sat, 30 Oct 2021 22:13:20 +0700 Message-ID: References: <583051.1635393898@apollo2.minshall.org> <860561.1635530303@apollo2.minshall.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <860561.1635530303@apollo2.minshall.org> Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 4 X-Spam_score: 0.4 X-Spam_bar: / X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-2.426, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1635606883; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=joxQcPlx+O3LFQZz8hdsTPAnFx1nU8MiC4dP6oopdso=; b=D8KEcyQACPOYFMMrDnrwadRm/uJhHSSd5Oy2zNTte/LH/jwQ4bCoAFwz1mlRaJG4dNnvEx aMQX/22n7DwJQp6WssZoEQ9jMfnoxdn48sVBbb8aPkxVlRyZyk80+W+brlpubPmFbmOHBG SNm50dekrDsDh7JVbL4/qFiCIuNplAXg7JCbwpry/Pm3eXU4fPJC9crP6507qXoUranP9W B5SvwrfSsIp17rn9lKmhPa46O+GV1y9Wbq/7vzh4eniavfqUY+0/BU6cp+1oqEItd4L7H7 xZLdJTm894rRApo2B5JJOVl3a57NrAcMvODg3RpqicvEG3MjDzXfFpqbxa8Quw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1635606883; a=rsa-sha256; cv=none; b=WaIkdg/bxZtAmMAt1hjmAgTirYXQ33YU4ZNd84tr3MGACsYmvs2K6LurNj1G1ZtTitcMXJ hTvzrIYx0YBtm5WmEM/cZoWgQhyD5BKMKrQURT5AT9e/ngltdNAAmxeD+iMMT1BLfAO7mA EjPXfDjs1mea7wwAzF0iDCDWLH1mpWo4iJD2dt3jiceKVmzHSbhYMnJ7UJVJvXzYm4wiWZ 4vqtuqiw84byWm+daiin0zW2nw2Jkrx0jwJfdgYc/Y8PVFavDiSRRXn3XFtznoJmhhWncM EnUzEH9lHa8VWIMAYuDjGw9jUz60LZTZx6od5RCHjiCc97Y5s7YwybAtOhO1Pw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -0.82 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: ED122B292 X-Spam-Score: -0.82 X-Migadu-Scanner: scn0.migadu.com X-TUID: n84nJnS+6NFb 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.