emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: mooss <mooss@protonmail.com>
To: Tom Gillespie <tgbugs@gmail.com>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: Multiple named code blocks
Date: Sun, 29 Nov 2020 00:40:48 +0000	[thread overview]
Message-ID: <Mx_kOqWZm_Lynt5W9yEq0OPNp5xZlbeIi1su_SiIaY9v_VeeqrYIYlweiXmxQfQHcVu3uBGK1a9yfGeSUyox1LyO99sRVys0Okb9POeEiqw=@protonmail.com> (raw)
In-Reply-To: <CA+G3_PMOqv0HeBd36N5nvfhmH=+iLzp0cv9RHVOUvb=fGmB1_w@mail.gmail.com>

Hi Tom,

The downsides you mention are making perfect sense, especially
the cd and rm examples, I did not thought about that and I agree
that this would be a dangerous default.

Another possibility would be to shield this behaviour behind a
header argument, for example by adding a "dimension" to the
"noweb" argument.
What I mean by "dimension" is that to my knowledge, the header-
arg "noweb" only has a, let's say, "when" dimension that can take
one value among "yes" "no" and "no-export", whereas "results" can
have several dimensions, hence the validity of ":results drawer
replace" as a header-arg.
This new dimension could be called the "duplicated" dimension and
take values among "contatenate", "first" or "last".
With this scheme, one could use the header-arg ":noweb yes
concatenate" to always expand noweb inclusions and handle
multiple code blocks via concatenation.

I can see a couple of potential problems with this approach:
 1. It might be better to avoid adding header-args left and right
    to keep complexity in check and this feature is arguably
    quite niche.
 2. This would solidify the idea that multiple code blocks
    sharing the same name is good practice in org documents,
    which it is not, as you explained.

Yet another option would be to not rely on the names but on
another header-arg like "addto" that instruct the noweb resolver
to concatenate the current block to another named code block.
Reusing the previous example,

#+name: Before foo
#+begin_src perl
my $value = 'Inside foo call';
#+end_src

Would become:

#+begin_src perl :addto "Before foo"
my $value = 'Inside foo call';
#+end_src

Yet another approach would be to add a "directive" (that's probably not the right terminology), like so:

#+addto: Before foo
#+begin_src perl
my $value = 'Inside foo call';
#+end_src

The last two approaches would solve problem 2) but not problem
1).
There would also be the problem of what to do when a code block
is "added to" before its definition, what should be done ?
Throwing an error, appending or prepending ?

Personally I would prefer the last approach, even though the
prepending problem remains to be solved, because the other
approaches are polluting the header arguments and look out of
place there.
In any case, I think that a mechanism to concatenate to an
existing code block is a valuable feature for a literate
programming system.

On another note, that is a bit embarrassing but I'm not too sure
about how I am supposed to respond to this email list, I just
clicked on "Reply all" in my webmail client and this results in a
mail specifically addressed to you Tom and a CC to the list.
That is also what is suggested by the "Reply instructions:"
section of the list, but I just want to be sure that I am not
disrespecting a rule or custom that escapes me.

Best regards,
Félix


  reply	other threads:[~2020-11-29  0:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-28 22:35 Multiple named code blocks mooss
2020-11-28 22:59 ` Tom Gillespie
2020-11-29  0:40   ` mooss [this message]
2020-11-29  3:24 ` Greg Minshall
2020-11-30 11:38   ` mooss
2020-11-29  8:28 ` Diego Zamboni
2020-11-30 11:39   ` mooss

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='Mx_kOqWZm_Lynt5W9yEq0OPNp5xZlbeIi1su_SiIaY9v_VeeqrYIYlweiXmxQfQHcVu3uBGK1a9yfGeSUyox1LyO99sRVys0Okb9POeEiqw=@protonmail.com' \
    --to=mooss@protonmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=tgbugs@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).