emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Rodrigo Morales <moralesrodrigo1100@gmail.com>
To: Greg Minshall <minshall@umich.edu>
Cc: emacs-orgmode@gnu.org, Eric S Fraga <e.fraga@ucl.ac.uk>
Subject: Re: How do you name your code blocks?
Date: Wed, 17 Feb 2021 15:31:18 -0500	[thread overview]
Message-ID: <87blcitp0p.fsf@gmail.com> (raw)
In-Reply-To: <1494323.1613545005@apollo2.minshall.org>

Greg Minshall <minshall@umich.edu> writes:

> Right now, names of source blocks are global to the .org file, and i
> don't suspect that will (or should) change.

Yep, I understand that. I explained a workaround for using short names
for code blocks and avoid name conflicts in

Greg Minshall <minshall@umich.edu> writes:

> i apologize for bringing it up, but the one thing that jumps out at the
> programmer part of me is that the python blocks in your code don't
> "know" what main.txt actually contains when they are executed, as there
> is no dependency on the correct "create-file" source block.  possibly,
> though, if you created some dummy :var (on the python "begin_src" lines)
> to express this dependency, it would help?  or, maybe it doesn't really
> matter?

I understand your point. I am currently expressing that dependency by
putting a =#+CALL= statement with =:results silent= above the Python
code block. However, doing that doesn't really express a dependency
because I need to execute the =#+CALL= statement first and then the
Python code block. It would be nice if we could associate a code block
(B) to another code block (A) so that (B) is execute before (A) is
executed. I created
thread]] in the mailing list asking this. One of the solutions mentioned
in that thread is to use the =:var= header argument which you mentioned
and works great.

From now on, I will be using the ID of the current subtreeas the suffix
(not prefix) of code block names so that name conflicts doesn't occur
between different subtrees and will express dependency between code
blocks by using the =:var= header argument.

Perhaps, having a =:pre= header argument, just as the =:post= header
argument exist, would help expressing depdency between code blocks in a
clearer way. I consider the =:var= header argument a hacky way to
associate two code blocks.

Rodrigo Morales.

  reply	other threads:[~2021-02-17 21:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 19:18 How do you name your code blocks? Rodrigo Morales
2021-02-16  4:53 ` Greg Minshall
2021-02-17  1:21   ` Rodrigo Morales
2021-02-16 12:03 ` Eric S Fraga
2021-02-17  1:27   ` Rodrigo Morales
2021-02-17  6:56     ` Greg Minshall
2021-02-17 20:31       ` Rodrigo Morales [this message]
2021-02-17  1:58 ` Kevin M. Stout
2021-02-17  9:57   ` Eric S Fraga

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=87blcitp0p.fsf@gmail.com \
    --to=moralesrodrigo1100@gmail.com \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=minshall@umich.edu \


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