Re: Multiple named code blocks

[mooss]

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