Re: [O] [BUG] Noweb reference eval syntax does not work

[Aaron Ecay]

Hi Rasmus, hi all,

2016ko maiatzak 8an, Rasmus-ek idatzi zuen:

[...]

> As you mention, we’d loose the ability to chain together multiple blocks.
> I reckon they are meaningfully the same language, so I don’t see a loss.
> The example shown in the manual also does not convince me of the
> usefullness of this.

Ditto.

> 
>> It is redundant with #+NAME: keyword and slightly broken. Also it
>> induces hacks like `org-babel-use-quick-and-dirty-noweb-expansion' to
>> work-around its shortcomings. 
>> 
>> Besides, it doesn't make much sense to add the same parameters to
>> a bunch of blocks, so I find the syntax dubious.
>> 
>> I understand it can be a handy shortcut for inserting multiple blocks,
>> but, all in all, I tend to think it would be simpler to just remove the
>> feature, along with `:noweb-sep' and
>> `org-babel-use-quick-and-dirty-noweb-expansion'.
> 
> I’m happy to kill it off in Org-9.  I don’t know how widely the chaining
> of blocks is used, though, and whether the fix is always as simple as
> uniting the blocks.

I think that we can provide a replacement to noweb-ref as follows:

* Code blocks
:PROPERTIES:
:header-args: :noweb-ref foo
:END:

#+begin_src python
block 1
#+end_src

#+begin_src python
block 2
#+end_src

* Concat

The old way

#+begin_src python
<<foo>>
#+end_src

The new way:

#+begin_src python
<<concat-blocks-of-lang-in-headline("python","Code blocks")>>
#+end_src

concat-blocks-of-lang-in-headline would have to be an elisp source block
implementing the appropriate behavior which is present in the document
or in the library of babel.

(And I think it would be good if the LoB contained some useful
predefined blocks like this one, in addition to those added by the
user.  A “standard library of babel” as it were.)

> 
>> What do you, and others, think? Is NAME enough for noweb syntax, or is
>> there a real need fo :noweb-ref?

To put it another way: it seems to me that the functionality of
:noweb-ref can be reimplemented in terms of other primitives.  And given
Nicolas’s comments about the complications and bugs it introduces, I’d
be in favor of deprecating and eventually removing it.

-- 
Aaron Ecay