From: Rodrigo Morales <moralesrodrigo1100@gmail.com>
To: emacs-orgmode@gnu.org
Subject: [feature request] The :pre header argument
Date: Thu, 18 Feb 2021 16:48:36 -0500 [thread overview]
Message-ID: <878s7ljbd7.fsf@gmail.com> (raw)
This message contains my thoughts on a feature request which I think
would be useful: The =:pre= header argument, it would be used to
execute a code block before the code block at point is executed. It
would be similar to the behavior of the =:post= header argument.
Here's a simple example that shows how =:pre= could be used
#+NAME: clean-path-experiments
#+begin_src dash
if [ ! -z "$my__experiments" ] && [ -d "$my__experiments" ]; then
find ~/e -mindepth 1 -maxdepth 1 -exec rm -rf {} +
fi
#+end_src
#+NAME: tree-command
#+begin_src dash
tree -a --noreport
#+end_src
#+NAME: create-dir-for-minimal-reproducible-example
#+HEADER: :pre clean-path-experiments()
#+HEADER: :post tree-command()
#+begin_src python
import os
[os.makedirs(_) for _ in ["a/foo", "a/bar", "b"]]
[os.mknod(_) for _ in ["a/1.txt", "a/2.txt", "a/foo/b.txt", "a/bar/b.txt", "b/b.txt"]]
#+end_src
#+RESULTS: create-dir-for-minimal-reproducible-example
#+begin_example
.
├── a
│ ├── 1.txt
│ ├── 2.txt
│ ├── bar
│ │ └── b.txt
│ └── foo
│ └── b.txt
└── b
└── b.txt
#+end_example
I think that such header argument would be useful because of two
main reasons:
* It would improve readability of code blocks by explicitly expressing dependency
By having a header argument for the sole purpose of expressing
dependencies between code blocks, the readability of header arguments
would be improved. Recall that it is currently possible to express
such dependency by calling a code block through a =:var <<name>>=
header argument but I think that =:var= header argument must only be
used for defining variables (be it from results obtained from
different code blocks or literals).
The first code block shown below show the differences between using
=:var= and =:pre= for the same scenario. =first-code-block= uses the
=:var= header argument while the =second-code-block= uses the =:pre=
header argument.
#+NAME: first-code-block
#+begin_src org
For our experimentation, let's start with an empty directory and let's
execute the first step.
,#+NAME: first-step
,#+HEADER: :results silent
,#+HEADER: :var e=clean-path-experiments
,#+begin_src dash
touch first-step.txt
,#+end_src
We know execute the second step.
,#+NAME: second-step
,#+HEADER: :results silent
,#+HEADER: :var e=first-step
,#+begin_src dash
touch second-step.txt
,#+end_src
Finally, we execute the third step.
,#+NAME: third-step
,#+HEADER: :results silent
,#+HEADER: :var e=second-step
,#+begin_src dash
touch third-step.txt
,#+end_src
#+end_src
#+NAME: second-code-block
#+begin_src org
For our experimentation, let's start with an empty directory and let's
execute the first step.
,#+NAME: first-step
,#+HEADER: :results silent
,#+HEADER: :pre clean-path-experiments()
,#+begin_src dash
touch first-step.txt
,#+end_src
We know execute the second step.
,#+NAME: second-step
,#+HEADER: :results silent
,#+HEADER: :pre first-step()
,#+begin_src dash
touch second-step.txt
,#+end_src
Finally, we execute the third step.
,#+NAME: third-step
,#+HEADER: :results silent
,#+HEADER: :pre second-step()
,#+begin_src dash
touch third-step.txt
,#+end_src
#+end_src
In my opinion, the second code block looks more readable than the
first one.
* it would add importance to the =:post= header argument
The =:post= header argument can be used in Org Mode 9.3 to execute a
given code block after the code block at point is executed; having a
header argument that does the opposite of the =:post= header argument
would give relevance to the =:post= header argument.
--
Greetings,
Rodrigo Morales.
IRC: rdrg109 (freenode)
next reply other threads:[~2021-02-18 21:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 21:48 Rodrigo Morales [this message]
2021-02-19 13:33 ` [feature request] The :pre header argument Rodrigo Morales
2021-02-20 1:50 ` Rodrigo Morales
2021-04-05 4:49 ` Ihor Radchenko
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=878s7ljbd7.fsf@gmail.com \
--to=moralesrodrigo1100@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).