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
