From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id R//DIhVsMGDqHwAA0tVLHw (envelope-from ) for ; Sat, 20 Feb 2021 01:55:33 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id uCUYHhVsMGAkfQAAB5/wlQ (envelope-from ) for ; Sat, 20 Feb 2021 01:55:33 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 83456154A5 for ; Sat, 20 Feb 2021 02:55:32 +0100 (CET) Received: from localhost ([::1]:57912 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDHUY-0004Fl-Jw for larch@yhetil.org; Fri, 19 Feb 2021 20:55:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58444) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDHTd-0004FO-SH for emacs-orgmode@gnu.org; Fri, 19 Feb 2021 20:54:33 -0500 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]:46104) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lDHTa-0000f0-O6 for emacs-orgmode@gnu.org; Fri, 19 Feb 2021 20:54:33 -0500 Received: by mail-io1-xd2a.google.com with SMTP id u8so7597212ior.13 for ; Fri, 19 Feb 2021 17:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZdrwSeaSmaqs+Xg88OcMmE3wAiMIag9avSTV0Y8Zx90=; b=qAXCELWBku7I8vGFBmatSAT5GFpsdqhenmUavgLmcg1CusH+IFb2gBdCOHIs4Ib+As QOznRYj39VUWa1jsVu6fZBq/4y0AsOn7vNA8JkhLIVXpwlz3gfu8S3RRB6/wJsGB2oVM +YCSoxbK1yC+fNgu3tlkwhK/ICJSC8T2Gg+dkRotf3iPUVKduAO526/T+VYWLVKZNBQ3 IqTpRJcAubZdQ4TmRUykkj8EpKFEk41+xFEo7I/GvWIk0KY9anwUy0aBKquf15vXPQ9k 3iYv80AqzGsuCIecKx+TuBTZTiU9gYM/nsZZ9MFNM2pe5uq+duXLKle+StwVfrrWIHOp Qd+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZdrwSeaSmaqs+Xg88OcMmE3wAiMIag9avSTV0Y8Zx90=; b=YO9BQWyQAHyBz3GhHiZk6cMJ3yTXkhYyOmdua5oHhXv1E/WPXtBYN7m1mFQ7SYi5GN uNv8xRheGzIf8zBxyghf7A1hvQozMZHM8y0zZoSIhV4BNM8UztNubaPVmDbdBmnnJ/VY iBCkrRpbJ/6WvbsX4Bz8N+T7r3n99Wn/4tvTTBYKlCmljQpnurdNG4dYpLlIkhRtWEg8 aMubQEkrE3IAlBhvgtENKEs82xp+5m76Q4HY7rTk/EWSwJRO5vYuVbxxB5IRA1baTR0r NK0gpHm/EK2anBvwRDneI6G89RPTa0im7rmLItz4xfon3Jj+P8lrheCSiBx3Iz0j8r3J U2rQ== X-Gm-Message-State: AOAM5300GJz2W98BWMN7l/Tbz2I+88zHhEbcrDKdAk10WjE4Zrjt7FkC 5PTSHzW13SqafFlpzgUsc2hk48/dAs2BzBK4hALDj9lY6Fc= X-Google-Smtp-Source: ABdhPJwYyXdBtdm8IGfUFeWjx0z9qbTG9Q8J3ucde6UouGWeiUK7zPLHyJRfxDHFAiyd+arEm9jGpr0dO4K2CL+UnsI= X-Received: by 2002:a6b:7619:: with SMTP id g25mr6709201iom.177.1613786068890; Fri, 19 Feb 2021 17:54:28 -0800 (PST) MIME-Version: 1.0 References: <878s7ljbd7.fsf@gmail.com> In-Reply-To: From: Rodrigo Morales Date: Fri, 19 Feb 2021 20:50:40 -0500 Message-ID: Subject: Re: [feature request] The :pre header argument To: org-mode-email Content-Type: multipart/alternative; boundary="00000000000061385305bbbad9c9" Received-SPF: pass client-ip=2607:f8b0:4864:20::d2a; envelope-from=moralesrodrigo1100@gmail.com; helo=mail-io1-xd2a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.07 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=qAXCELWB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 83456154A5 X-Spam-Score: -2.07 X-Migadu-Scanner: scn1.migadu.com X-TUID: GZaQvN04I4V/ --00000000000061385305bbbad9c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've provided more relevant information on this feature request [[ https://codeberg.org/rdrg109/gists/src/branch/main/feature-request-pre-head= er-argument.org][here]]. Please consider reading that instead of the first message on this thread. On Fri, 19 Feb 2021 at 08:33, Rodrigo Morales wrote: > You can read this message with proper formatting here ( > https://codeberg.org/rdrg109/gists/src/branch/main/the-pre-header-argumen= t.org > ). > > On Thu, 18 Feb 2021 at 16:52, Rodrigo Morales < > moralesrodrigo1100@gmail.com> wrote: > >> >> This message contains my thoughts on a feature request which I think >> would be useful: The =3D:pre=3D 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 =3D:post=3D header argument. >> >> Here's a simple example that shows how =3D:pre=3D 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 >> . >> =E2=94=9C=E2=94=80=E2=94=80 a >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 1.txt >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 2.txt >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 bar >> =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b.txt >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 foo >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b.txt >> =E2=94=94=E2=94=80=E2=94=80 b >> =E2=94=94=E2=94=80=E2=94=80 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 =3D:var <>=3D >> header argument but I think that =3D:var=3D 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 >> =3D:var=3D and =3D:pre=3D for the same scenario. =3Dfirst-code-block=3D = uses the >> =3D:var=3D header argument while the =3Dsecond-code-block=3D uses the = =3D:pre=3D >> 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=3Dclean-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=3Dfirst-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=3Dsecond-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 =3D:post=3D header argument >> >> The =3D:post=3D 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 =3D:post=3D header argumen= t >> would give relevance to the =3D:post=3D header argument. >> >> -- >> Greetings, >> Rodrigo Morales. >> >> IRC: rdrg109 (freenode) >> > --00000000000061385305bbbad9c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've provided more relevant information on this featur= e request [[https://codeberg.org/rdrg109= /gists/src/branch/main/feature-request-pre-header-argument.org][here]].= Please consider reading that instead of the first message on this thread.<= br>

On Fri, 19 Feb 2021 at 08:33, Rodrigo Morales <moralesrodrigo1100@gmail.com> wrote:
You = can read this message with proper formatting here ( https://codeberg.org/rdrg109/gists/src/branch/main/the-pre-head= er-argument.org ).

On Thu, 18 Feb 2021 at 16:52, Rodrigo Morales <moralesrodri= go1100@gmail.com> wrote:

This message contains my thoughts on a feature request which I think
would be useful: The =3D:pre=3D 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 =3D:post=3D header argument.

Here's a simple example that shows how =3D:pre=3D could be used

#+NAME: clean-path-experiments
#+begin_src dash
if [ ! -z "$my__experiments" ] && [ -d "$my__experim= ents" ]; then
=C2=A0 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&quo= t;]]
[os.mknod(_) for _ in ["a/1.txt", "a/2.txt", "a/fo= o/b.txt", "a/bar/b.txt", "b/b.txt"]]
#+end_src

#+RESULTS: create-dir-for-minimal-reproducible-example
#+begin_example
.
=E2=94=9C=E2=94=80=E2=94=80 a
=E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 1.txt
=E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 2.txt
=E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 bar
=E2=94=82=C2=A0=C2=A0 =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 b.t= xt
=E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 foo
=E2=94=82=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=E2=94=94=E2=94=80=E2=94=80 b.txt<= br> =E2=94=94=E2=94=80=E2=94=80 b
=C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 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 depe= ndency

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 =3D:var <<name>&= gt;=3D
header argument but I think that =3D:var=3D 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
=3D:var=3D and =3D:pre=3D for the same scenario. =3Dfirst-code-block=3D use= s the
=3D:var=3D header argument while the =3Dsecond-code-block=3D uses the =3D:p= re=3D
header argument.

#+NAME: first-code-block
#+begin_src org
For our experimentation, let's start with an empty directory and let= 9;s
execute the first step.

,#+NAME: first-step
,#+HEADER: :results silent
,#+HEADER: :var e=3Dclean-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=3Dfirst-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=3Dsecond-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= 9;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 =3D:post=3D header argument

The =3D:post=3D 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 =3D:post=3D header argument would give relevance to the =3D:post=3D header argument.

--
Greetings,
Rodrigo Morales.

IRC: rdrg109 (freenode)
--00000000000061385305bbbad9c9--