From: Tim Cross <email@example.com>
Subject: Re: [PATCH] Allow tangling to a list of files
Date: Wed, 07 Jul 2021 14:09:52 +1000 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Vladimir Lomov <email@example.com> writes:
> [[PGP Signed Part:Undecided]]
> Hello Jacopo.
> ** Jacopo De Simoi <firstname.lastname@example.org> [2021-07-06 11:24:40 -0400]:
>> Dear Vladimir,
>> thanks for your reply.
>> Let me show you two examples; they are both WIP and incomplete, but you'll get
>> the gist.
>> - Example 1
>> This is my literate config for .zshrc; as you can see different blocks are
>> tangled to different set of files; hence the output files differ (as some
>> blocks are present and other are not)
> I couldn't find in Org manual how tangling should work if there are several
> source code blocks with the same file name for ':tangle'. The Org manual
> section "15.8 Extracting Source Code" is a bit obscure. There are these two
> When Org tangles code blocks, it expands, merges, and transforms
> them. Then Org recomposes them into one or more separate files, as
> configured through the options.
> The second sentence assumes that it might be possible to tangle to more than
> one file but possible options for ':tangle' don't give certain answer:
> Export the code block to source file. The file name for the source
> file is derived from the name of the Org file, and the file extension
> is derived from the source code language identifier.
> Example: ‘:tangle yes’.
> Export the code block to source file whose file name is derived from
> any string passed to the ‘tangle’ header argument. Org derives the
> file name as being relative to the directory of the Org file’s
> location. Example: ‘:tangle FILENAME’.
> If I understand first choice correctly then the only source block ("the code
> block") will be tangled (exported) to a source file. What Org will do if there
> are several source blocks? Concatenate them or write to a file only last one?
> (I didn't test that).
> The same applies to 'FILENAME' case: what Org will do if there are several
> source code blocks with the same 'FILENAME' for ':tangle'.
> I would say that you use here undocumented feature and you workflow could be
> broken if in some future Org version developers decide to implement only
> documented features.
As it stands at the moment, if the :tangle keyword is followed by a
filename, that block will be tangled into that file. If there is more
than one block with the same filename, the blocks will all be
concatenated into the same file. If you have multiple source blocks, but
with different filenames for the blocks, multiple files will be created
when you tangle the file - one file for each unique filename given to
the :tangle argument in each block.
I use this to generate my emacs config. I have both an early-init.el and
an init.el. These files are created from multiple source blocks where
some blocks have :tangle early-init.el and some have :tangle init.el.
(actually, I have changed that now. I tangle to tangle-early-init.el and
tangle-init.el. I then have a simple 'install.sh' script which first
moves the old early-init.el and init.el to new files with a timestamp
added to the name i.e. init.el-20210722 and then it installs the new
init files, renaming them to early-init.el and init.el).
I'm not sure this is an undocumented feature. The manual just says that
the code will be tangled into the file specified with the :tangle
keyword. Nothing states the filename can only appear once or you cannot
have different filenames for different blocks.
If you don't specify a filename i.e. :tangle yes, the block will be
tangled into a file with the same name as the org file and the extension
appropriate to the language in the source block. For example, if my org
file is called emacs-config.org and I just have :tangle yes, I will get
the source tangled into emacs-config.el. Same will happen if I just have
the keyword :tangle.
When I don't want a source block added to a file, I just add :tangle no
to the block header. This is a handy way of removing something from a
config file. I find it useful when trying to track down problems with my
emacs init as I can quickly remove lots of stuff, generate a new config
and see if the issue persists. I find this easier than commenting and
uncommenting multiple lines in my init file. I also find it useful when
I run into a problem with something (possibly due to a package update)
as my source blocks are all broken up into specific bits of
configuration which are as far as possible completely independent of
each other. For example, a while ago, I had problems with one of the
magit add on packages I use after it was updated. I changed the header
to :tangle no, generated a new init file and waited until a new version
of the package was released. This happened a few days later and I just
changed the header back to :tangle init.el and generated the new config
and all was back to normal.
next prev parent reply other threads:[~2021-07-07 4:29 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 [this message]
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.
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).