From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 31ZLGJ0z5mByugAAgWs5BA (envelope-from ) for ; Thu, 08 Jul 2021 01:07:09 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id e7toE50z5mA5JgAAB5/wlQ (envelope-from ) for ; Wed, 07 Jul 2021 23:07:09 +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 57F381FE83 for ; Thu, 8 Jul 2021 01:07:08 +0200 (CEST) Received: from localhost ([::1]:47948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1GdH-0004ls-EB for larch@yhetil.org; Wed, 07 Jul 2021 19:07:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1Gcu-0004ld-Qy for emacs-orgmode@gnu.org; Wed, 07 Jul 2021 19:06:44 -0400 Received: from mail.math.toronto.edu ([128.100.68.68]:35525) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1Gcs-0002Z6-Iq for emacs-orgmode@gnu.org; Wed, 07 Jul 2021 19:06:44 -0400 Received: from bl4ckspoons.localnet (coxeter.math.toronto.edu [128.100.68.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jacopods) by mail.math.toronto.edu (Postfix) with ESMTPSA id 039884219A9; Wed, 7 Jul 2021 19:06:38 -0400 (EDT) To: Tim Cross Cc: emacs-orgmode@gnu.org Subject: Re: [PATCH] Allow tangling to a list of files Date: Wed, 07 Jul 2021 19:06:37 -0400 Message-ID: <3116936.aeNJFYEL58@bl4ckspoons> In-Reply-To: <87h7h7nakd.fsf@gmail.com> References: <-0ZoEP_lzUvrnWSq9TwiYHNJ0Spa94xjiTOF0TU8np0pYgHEPx-62_dr5xBMd3VUu7frSRXxiAFje99v2jeaJg==@protonmail.internalid> <6nablMuhQkeviB-6VFvbgkSFIQUX0t1Cn9X8VKPNkMNmTx_r0NlLhnpTJQyUB9EjTZEtB_1xnumcRgd_UEl_mQ==@protonmail.internalid> <87h7h7nakd.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3122913.44csPzL39Z"; micalg="pgp-sha256"; protocol="application/pgp-signature" Received-SPF: softfail client-ip=128.100.68.68; envelope-from=jacopods@protonmail.com; helo=mail.math.toronto.edu X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=ham 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" Reply-to: Jacopo De Simoi From: Jacopo De Simoi via "General discussions about Org-mode." X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1625699228; h=from:from:sender:sender:reply-to: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=lKX8W8VU4O0rN+F+vZ1Q9ww914QBUCDvCiyVoPtjmyw=; b=oQh6H/gAjh5ppgsEnd3Z0fVpeq+9NiBdjYcjFMclQdZgjX+DaFpfWETTJIYOkoXCwdWoEq 01WlgFZlsa4Y/mwKwWt3Afzu7jXVCCucPobjmGKuVK2W39JCrK1Qq4M/ANgzA1uCBPqPSI hnczsQdqA8F6bOT2uNld46oBYqgVXpMdEiK2wx2kBjVzQjE4H5iv0uDy9jPCV6UfYuIm2l uBKQMiJV/1BBkEsOpIDRzK8sEe3M4cqxmHKLGj8TySH+DQcIKbKVG5oE5Ll3dgTvimnEmH sI986Mh6upTeOxOhDnKVWmpgrH5Z5JOnQshFekQLdvW0I3U81TF88ix54cPmaQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1625699228; a=rsa-sha256; cv=none; b=SDF6H4NqMZxUd5NR5/BTwiwQnnCvZqozUb/VDyfPQAleN1iUWdRqtD21gu+OWvd7bSzekf zG7xfitwPUnLcPql3E4TLM2Ov52TK+GNqIl5OmMELJunLwuAbbXSGYW0bWlbYEr98WwYIQ GQrv4uqLSy9YP30KV20KoLdz0DFKGuEmXeDl2bh1dBSyE7mDWNEI9KPsjTzgMTPKWwwd6g oP0tUQPHgNS+1+9WO9dw4Ms5OcO2gpeUPJPZBeDYBZitVtZG+evu2NqYagt4rgp4iKvtIB hPBd9kvqoOPQqPr1NYWMlkX9ZmNYFg2CxKcM+HyhP69niy6MXuEMOyR4LGdZ0A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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: -4.51 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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: 57F381FE83 X-Spam-Score: -4.51 X-Migadu-Scanner: scn0.migadu.com X-TUID: UZ9GWSY7TpcU --nextPart3122913.44csPzL39Z Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Jacopo De Simoi To: Tim Cross Cc: emacs-orgmode@gnu.org Subject: Re: [PATCH] Allow tangling to a list of files Date: Wed, 07 Jul 2021 19:06:29 -0400 Message-ID: <3116936.aeNJFYEL58@bl4ckspoons> In-Reply-To: <87h7h7nakd.fsf@gmail.com> References: <-0ZoEP_lzUvrnWSq9TwiYHNJ0Spa94xjiTOF0TU8np0pYgHEPx-62_dr5xBMd3VUu7frSRXxiAFje99v2jeaJg==@protonmail.internalid> <6nablMuhQkeviB-6VFvbgkSFIQUX0t1Cn9X8VKPNkMNmTx_r0NlLhnpTJQyUB9EjTZEtB_1xnumcRgd_UEl_mQ==@protonmail.internalid> <87h7h7nakd.fsf@gmail.com> Dear Tim, On Tuesday, July 6, 2021 3:30:40 AM EDT Tim Cross wrote: > Jacopo De Simoi via "General discussions about Org-mode." writes: > > Hi Greg, > > > > thanks for your comments! > > > > On Tuesday, July 6, 2021 12:43:54 AM EDT Greg Minshall wrote: > >> hi, Jacopo, > >> > >> i'm not convinced this is needed over and above your old "solution" of > >> using <> witn N-different source blocks, each :tangle'ing to a > >> different file. > > > > To be honest I never quite managed to get it work... =) > > > > My point here is to be able to have one org file tangle'ing to several, > > slightly different outputs. Ideally I want to use one readable literate > > config for all my machines; the config can then be published (or > > exported) to html > > > > Say I want to create an org file to tangle .tmux.conf (or .zshrc) for > > different machines; then most of the conf file would be the same (and > > each such block would be tangled to all files) whereas some specifics > > could be tangled to corresponding files only (e.g. ALIASes or EDITORs) > > > > Even if a solution using noweb could work, I find being able to tangle to > > a > > list of files more readable and elegant. Especially when exporting the org > > in an external format, I think the noweb solution would look like a hack, > > whereas a solution with tangle-to-list would be much easier to parse. > > > >> but, i'm curious -- in the example you sent, did you miss a ":tangle" on > >> the "#+begin_src" line? > > > > Yikes! of course I did! Good catch. > > > >> > #+begin_src sh '("filename1" "filename2") > >> > #my script > >> > #+end_src > > I'm not sure I fully understand the rationale behind this patch. It > seems to be very niche oriented and not a terribly useful general > feature. It feels like it is just a partial solution to a problem (i.e. > generate multiple different files from the same org file). If this is > the case, then you probably need some additional control structures to > determine which bits/blocks go into which files. From what I can see, > all the patch is doing is creating multiple files, which I imagine would > then need to be modified anyway? > > If I understand it correctly, all the files will end up with the same > content. This seems odd to me. Am I missing something (like some ability > to have different contents tangled to different files)? > > If it is just generating multiple copies of the same file, I don't > really see the value. It would be less processing/overhead to just > create one file and then copy it (possibly copying it to different > locations, such as a tramp filespec). Using the 'devops' style of org > files, this could even be coded into a script block which could be > executed after tangling. In fact the files are different, since each source block is tangled to a possibly different subset of files. The logic for which files to tangle according to which parameter or tags can be implemented by some lisp magic such as #+begin_src sh :tangle (filenames-according-to-situation) #+end_src So my patch provides the framework to do this, but the implementation is left to the author. I agree that if you tangle to shell or to any programming language, you can set up the checks for each usecase in the programming language itself. I developed this solution for plaintext config files (e.g. xkb maps, or KDE shortcut config files) which are static and parsed as a single chunk. I admit that the use case is quite specific, but it seemed to me a quite natural generalization of the current behavior, and worth adding. Thanks for the discussion! It's really helpful to put things in perspective. > > Personally, I've used a different approach to a similar problem. For > example, my .zshrc and init.el files have conditional tests which check > either the hostname or platform type and set things accordingly. This > way, I only ever have one .zshrc and one init.el file for all systems, > but they behave differently based on the system they are running on. > When the config does not support conditional tests, then I'll have > different source blocks included in the tangle. Currently, I just turn > off blocks I don't want (:tangle no), but I guess I could do something > more sophisticated using noweb or tags, but the manual setting has > worked fine so far as I don't have many files requiring this. > > -- > Tim Cross --nextPart3122913.44csPzL39Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEW5qu6ikPTsnoIrBSsQAjsHXzOiMFAmDmM3UACgkQsQAjsHXz OiOb1wgAxRx+eFplCugp+K12tYIfctbjVzGz2Al39lj5mw4LCfwlLlIGgwFO776K o6wNHubWMxU7UiWUfGX8DTLM5PaNt6ktclzM1h9Pj7wCf27N6c7cVAlKpUYu7iW0 su9sFz8beGh/vRVCfK6dHfLIaNXFITzCkHf2YfzF/xbmSz+x31j5NpydP/vHUIAf AWp5InkGfDA72uBBvyrJHJX5oC8UngPSRfYdP6ptlwrGU+BfMQ6cLYEYHKyt8FWQ NObTsvDTPyL/wxy5ZEk/auBJGtaRkf1MbFgToqI2X+8lZlUTEgS2BDxykwZbVh0P P7qcUVfusM+qzuncQyCRAnAT9ymgbA== =BYK7 -----END PGP SIGNATURE----- --nextPart3122913.44csPzL39Z--