emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jacopo De Simoi via "General discussions about Org-mode." <emacs-orgmode@gnu.org>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.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)
In-Reply-To: <87h7h7nakd.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4439 bytes --]

Dear Tim, 

On Tuesday, July 6, 2021 3:30:40 AM EDT Tim Cross wrote:
> 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.

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  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_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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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=3116936.aeNJFYEL58@bl4ckspoons \
    --to=emacs-orgmode@gnu.org \
    --cc=jacopods@protonmail.com \
    --cc=theophilusx@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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