From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id uE2hDRCstmWYAQAA62LTzQ:P1 (envelope-from ) for ; Sun, 28 Jan 2024 20:33:36 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id uE2hDRCstmWYAQAA62LTzQ (envelope-from ) for ; Sun, 28 Jan 2024 20:33:36 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; 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=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706470416; 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; bh=aqOfO2LVcuEVqmpG0rWSGL8wQYcgUQh03/OtrZShxA8=; b=WZ4oiCUSHC29hXGan9zYQbE2iy4c1BDDMqw+otQZQVkmlELfYPVFzgYlNNYmXw/cVpsw+d Pg/Gl3LG2jJz5x2/XEMesGCQbMlFMl5n6pCZsjdumNi+fvAqJFuWSfEC/i8E7NNrcpj216 Bwake9NedulI1uVOLquLt8TohB6LNEJ6z1seck1cs7kiT4dynCotsvYdMqy2rRXMpNrYEL Vf7O2YBPY65cIizNWTBQc32CeMBrqBVFCxON72KlGtfep8d6LaPm9voivlgPKSKfMnDhnW OnueFzMXmqjOb1oHKLStV4hlWeO9c4ajt8hLBi+sdplLuDQw4X37Tnga2ZTh7Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706470416; a=rsa-sha256; cv=none; b=Jh40ZZGQNAhZBEu2M50eLfD/23tjrLmx6O4GwvuqbIym5b8OnskRQas4wy1SWNuFpUSUxd ODhWF57lXlIGTInrwWZSi6Fmz+zfxV75NLKpDoN66YnvWkJvR3L4tDaYjq8PPcC7QjPx3p 2NmGLtBwRJuqmk4rgw0MdkrPiGHKnjC6ZztWOU1+005jjTNM+ui4I1HniwVSLBFrzMbL8V IwH15t6u1ACUPV44AC97kG+XG/F+lE2W6LUoq9yKCFci8Q9rEn6RwJV7zBjC0VHM/2ks7L SQnna7IWsNcIWdK8UqRVWZ/qcA0dHNqqXpsSOfxrbwugWK9Kcj862T/X2cf+oQ== 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 E61646BBC4 for ; Sun, 28 Jan 2024 20:33:35 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUAto-0002mS-Au; Sun, 28 Jan 2024 14:33:00 -0500 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 1rUAtm-0002lm-NV for emacs-orgmode@gnu.org; Sun, 28 Jan 2024 14:32:58 -0500 Received: from mxout014.mail.hostpoint.ch ([2a00:d70:0:e::314]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUAtk-00028u-Pa for emacs-orgmode@gnu.org; Sun, 28 Jan 2024 14:32:58 -0500 Received: from [10.0.2.44] (helo=asmtp014.mail.hostpoint.ch) by mxout014.mail.hostpoint.ch with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1 (FreeBSD)) (envelope-from ) id 1rUAte-00000000AHR-0OMN; Sun, 28 Jan 2024 20:32:50 +0100 Received: from [2a02:21b4:c40c:1000:263a:887f:cbe6:9d9b] (helo=COLA) by asmtp014.mail.hostpoint.ch with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1 (FreeBSD)) (envelope-from ) id 1rUAtd-00000000Dgn-3uCI; Sun, 28 Jan 2024 20:32:50 +0100 X-Authenticated-Sender-Id: olivier.lischer@liolin.ch References: <877cjzhjtg.fsf@liolin.ch> <87wmryelfo.fsf@localhost> User-agent: mu4e 1.10.8; emacs 29.2 From: Olivier Lischer To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: [PATCH] ob-tangle: Add flag to optionally remove files before writing Date: Sun, 28 Jan 2024 20:07:33 +0100 In-reply-to: <87wmryelfo.fsf@localhost> Message-ID: <878r49i78e.fsf@liolin.ch> MIME-Version: 1.0 Content-Type: text/plain X-Vs-State: 0 Received-SPF: pass client-ip=2a00:d70:0:e::314; envelope-from=olivier.lischer@liolin.ch; helo=mxout014.mail.hostpoint.ch X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Spam-Score: -6.43 X-Migadu-Queue-Id: E61646BBC4 X-Spam-Score: -6.43 X-Migadu-Scanner: mx11.migadu.com X-TUID: ubG/6ecM/2IO Ihor Radchenko writes: > Olivier Lischer writes: > >> In December last year was a change introduced, that a file should not be >> removed before >> tangling (https://lists.gnu.org/r/emacs-orgmode/2021-05/msg00337.html). >> In an older bug report >> (https://lists.gnu.org/r/emacs-orgmode/2021-05/msg00337.html) >> the decision was to remove the file before writing. >> I added a variable to switch between both behaviors. > > Thanks for the patch, but may you please explain why introducing such > variable is useful? Sure. I configure all my .dotfiles in an Org mode file and tangle the configuration in the right places. The tangled files are all read-only to prevent accidentally editing of the "right" configuration file. With the current tangling mechanism, this results in a "Permission denied" error because the function writes to a read-only file. In a earlier version this use case was possible because the file was recreated before writing to it. There are also other people with the same workflow. See an older post to the mailing list (https://lists.gnu.org/r/emacs-orgmode/2021-05/msg00337.html). Some other have the opposite problem. They do not want the function to remove the file before tangling because it is a symlink. See this post on the mailing list (https://list.orgmode.org/orgmode/CAPHku6O9NfVMAfmE3_ahmpJea_2Qm0mJMFX6qPpT8uiQ94KMZA@mail.gmail.com/) To achieve both use cases, I think an additional variable could be useful. Best Regards Oli