[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Allow tangling to a list of files

From: Tim Cross
Subject: Re: [PATCH] Allow tangling to a list of files
Date: Tue, 06 Jul 2021 17:30:40 +1000
User-agent: mu4e 1.5.13; emacs 28.0.50

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]