From: Jacopo De Simoi via "General discussions about Org-mode." <email@example.com>
To: Tim Cross <firstname.lastname@example.org>
Subject: Re: [PATCH] Allow tangling to a list of files
Date: Wed, 07 Jul 2021 19:06:37 -0400 [thread overview]
Message-ID: <3116936.aeNJFYEL58@bl4ckspoons> (raw)
[-- Attachment #1: Type: text/plain, Size: 4439 bytes --]
On Tuesday, July 6, 2021 3:30:40 AM EDT Tim Cross wrote:
> Jacopo De Simoi via "General discussions about Org-mode." <emacs-
> > 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 <<noweb>> 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)
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-07-07 23:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 18:54 [PATCH] Allow tangling to a list of files Jacopo De Simoi
2021-07-06 2:57 ` Vladimir Lomov
2021-07-06 4:43 ` Greg Minshall
2021-07-06 5:09 ` Jacopo De Simoi via General discussions about Org-mode.
2021-07-06 6:11 ` Vladimir Lomov
2021-07-06 15:24 ` Jacopo De Simoi via General discussions about Org-mode.
2021-07-07 3:27 ` Vladimir Lomov
2021-07-07 4:09 ` Tim Cross
2021-07-07 5:01 ` Jacopo De Simoi
2021-07-07 6:56 ` Greg Minshall
2021-07-07 11:05 ` Jacopo De Simoi
2021-07-09 12:26 ` Vladimir Lomov
2021-07-09 13:39 ` Jacopo De Simoi
2021-07-09 22:47 ` Tim Cross
2021-07-06 7:30 ` Tim Cross
2021-07-07 23:06 ` Jacopo De Simoi via General discussions about Org-mode. [this message]
2021-07-07 23:28 ` Tim Cross
2021-07-08 0:01 ` Jacopo De Simoi
2021-07-08 0:41 ` Tom Gillespie
2021-07-08 16:41 ` Trust me I am a Doctor
2021-07-08 17:42 ` Jacopo De Simoi
[not found] <-0ZoEP_lzUvrnWSq9TwiYHNJ0Spa94xjiTOF0TU8np0pYgHEPx-62_dr5xBMd3VUu7frSRXxiAFje99v2jeaJgemail@example.com>
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 \
* 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).