emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Allow tangling to a list of files
Date: Tue, 06 Jul 2021 17:30:40 +1000	[thread overview]
Message-ID: <87h7h7nakd.fsf@gmail.com> (raw)
In-Reply-To: <1903689.usQuhbGJ8B@bl4ckspoons>

Jacopo De Simoi via "General discussions about Org-mode." <emacs-orgmode@gnu.org> 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 <<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. 

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

  parent reply	other threads:[~2021-07-06  7:53 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 [this message]
2021-07-07 23:06       ` Jacopo De Simoi via General discussions about Org-mode.
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_dr5xBMd3VUu7frSRXxiAFje99v2jeaJg==@protonmail.internalid>

Reply instructions:

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 \
    --in-reply-to=87h7h7nakd.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* 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).