From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id gITnHXC/5mbaagEAe85BDQ:P1 (envelope-from ) for ; Sun, 15 Sep 2024 11:05:20 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id gITnHXC/5mbaagEAe85BDQ (envelope-from ) for ; Sun, 15 Sep 2024 13:05:20 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=keeTzhPa; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1726398320; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=fMm/EN0nVNl4dGUz2D/FaOdReWp0Y/zz6mi2QFQsyAY=; b=YH4FImbLKKzrLNomwNEPmIdvDcS4sg+jqI/9622jUVOfitO52fPluyLUoP762jmqyD3Kx4 VV7e9fxQLG2zlhuJWU+Sb8MVUIyDWqRaCvxQnoNBSDDMQuE2QjMyUw5IJaynOcpCwz8EER 8Tq1kRvgNJukoxQqIcflsOo6rLD6yyHXL/r9063xGF2wruPU4VGh81IgvNd/8lLZE53AjN pLAzohYFih2nNPO9AzkRYgcJOiNBMbP3qISk1Qskyhsa/u11xIpy0LVS6HPmZLWcHj9chz LI1LdnTVlDJMlQkg1s8I1G1rcFoStTlf3THJGGmo58RG8nNXpNoR7IDGHDRtZw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=keeTzhPa; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1726398320; a=rsa-sha256; cv=none; b=ldjIG8dKTTWCytm5WpdgLOZToEvgmKWZRGtW85FtgrtOdZSa88vXtBIYq2r0ZJX6bOOKb/ lru/tVTwi9a1/Nv7snkDcR6s4DagUfQro6EE4iOLaTMF5tDTrCvv7WkDx+cfDaBlb7oNeV CNZyJBstQvBaWcOwUUq7sMkdUfrLgc6aL2ecFPdziWzEJf63s053FqwqLSeluWXJ0VAOht b2BqJZPVlr2+hA0B83ZOsAvvl7hE5rX0LnD2Wjmp+5+NNuoLwFQT1o8Y5a7ChE+V/ntmFF Nl6h92MbXR20my+aiFLfcgTHuzSnFpTOoZMWJEWVWK1DEKwydKzB/pyDh8+gzA== 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 606977BC87 for ; Sun, 15 Sep 2024 13:05:20 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spn3E-0005Hr-Ra; Sun, 15 Sep 2024 07:04:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spn3C-0005HQ-6u for emacs-orgmode@gnu.org; Sun, 15 Sep 2024 07:04:18 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spn3A-0000tN-BC for emacs-orgmode@gnu.org; Sun, 15 Sep 2024 07:04:17 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9F0E2240103 for ; Sun, 15 Sep 2024 13:04:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1726398252; bh=LDJKWDLJ9FZ+zb8X9Hg6xEIKbWbaqaLG65Lrt2VPrTE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=keeTzhPaA69VQYbxxlQOas8lzC7jYmDK15Oxt+LGxUIObuiY0DgiscfPAVo2pKq1P UfQJ0SWegvaFhqRdCycM3zWdAQb4lfgPuePU1vGXPydToz1O+Vfi9Ycd7+wcRqRwCB JkXZct9MlA4NNIoEksGgNJBHSjaZo1XLMloOIA+waovBY9dhoKH1DcglT5IgWuZiJx amhPDgAhos1CRB65to6A8w480TSNdFUqKiS9LGUH6y7pTxY7dCC+fjyBPCCVOjcp0o WuRkP3Ivw7Go68qaZbLhH6m6ZCci/lIn43++Cj1n4owhELyy6+RD+NDS7fHkcxaf3n gPoNTd/yE1AyQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4X64tL3kvvz6twS; Sun, 15 Sep 2024 13:04:10 +0200 (CEST) From: Ihor Radchenko To: Gilles Marait Cc: emacs-orgmode , emmanuel agullo Subject: Re: Change behavior of "org-babel-tangle-publish" from org 9.6 to 9.7 -- deleting source files and not tangling properly In-Reply-To: <1781466320.35797146.1725958169824.JavaMail.zimbra@inria.fr> References: <652111520.30366591.1725288746643.JavaMail.zimbra@inria.fr> <87tteopvxw.fsf@localhost> <1781466320.35797146.1725958169824.JavaMail.zimbra@inria.fr> Date: Sun, 15 Sep 2024 11:05:40 +0000 Message-ID: <878qvtkwhn.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 606977BC87 X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -9.73 X-Migadu-Spam-Score: -9.73 X-TUID: Wcc7f1KKITnc Gilles Marait writes: > Hi Igor, > > Thanks for your answer. > Yes, with org 9.6, I end up with two code.cpp as your said, one in "." and one in "src". > > I think the line you're pointing to is indeed the problem This is a bit tricky. The new behavior is not exactly a bug - you just relied upon undocumented behavior of `org-babel-tangle-publish' not cleaning up the tangled files. On the other hand, I can see tangled files being removed during publishing as unexpected - what if the same set of files is used for actual tangling (e.g. of config files). In such scenario, the configs will be moved, potentially breaking workflows. IMHO, it makes more sense to preserve _and also document_ (in the docstring) the old behavior. We just need to make sure that the bug fixed in 478576749d does not re-surface - when publishing directory is "." the old code failed trying to copy tangled file into self. I think that we can simply call `org-publish-attachment' on every tangled file in `org-babel-tangle-publish' - `org-publish-attachment' takes care about the situation when the tangled file is already in the publishing dir. Would you be interested to submit a patch fixing the issue as I described? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at