Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-23 Thread Nicolas Goaziou
Hello, Greg Minshall writes: > below is a format-patch. i signed FSF papers for emacs a number of > years ago (and for gawk more recently). Perfect. I applied it. Thank you! Regards, -- Nicolas Goaziou

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-22 Thread Greg Minshall
Nicolas, below is a format-patch. i signed FSF papers for emacs a number of years ago (and for gawk more recently). cheers, Greg From e2d440186ccf62216406abb440455edbac72ba79 Mon Sep 17 00:00:00 2001 From: Greg Minshall Date: Wed, 22 Apr 2020 14:45:52 -0700 Subject: [PATCH] some clarification

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-22 Thread Nicolas Goaziou
Greg Minshall writes: > two minor edits i might make to the first paragraph, 1) to make clear > that #+name: names only one block, and 2) to (maybe?) simplify the > latter part of the same paragraph, while, at the same time, trying to > keep a strong mention of the distinction between =NAME= and

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-22 Thread Greg Minshall
hi, Nicolas, thanks, and sorry, i should have git-pull'd. the new version seems very nice to me. two minor edits i might make to the first paragraph, 1) to make clear that #+name: names only one block, and 2) to (maybe?) simplify the latter part of the same paragraph, while, at the same time,

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-22 Thread Nicolas Goaziou
Hello, Greg Minshall writes: > Nicolas, > > thank you. wordsmithing opens up endless possibilities, so i don't know > that the following is at all an improvement on your suggestion. but, it > occurs to me to get the importance of =noweb-ref=, and its role in > concatenation, brought out early

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-21 Thread Greg Minshall
Nicolas, thank you. wordsmithing opens up endless possibilities, so i don't know that the following is at all an improvement on your suggestion. but, it occurs to me to get the importance of =noweb-ref=, and its role in concatenation, brought out early on the "page". one paragraph currently

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-20 Thread Nicolas Goaziou
Hello, Greg Minshall writes: > thanks for the history! sounds like a good tradeoff. i agree, a bit > more documentation would be good. I sligthly reworded Noweb references section in the manual. Please let me know if that is clearer. Regards, -- Nicolas Goaziou

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-19 Thread Greg Minshall
Nicolas, thanks for the history! sounds like a good tradeoff. i agree, a bit more documentation would be good. cheers, Greg

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-19 Thread Nicolas Goaziou
Greg Minshall writes: > Nicolas, thanks. i take it this is a change from (recent?) past > behavior? I think this was done between Org 9.1 and 9.2, the final step probably being 99dbca3d4f2fb30f35309a0bf4c324535b7dc9f3 > it was kind of nice the old way, but i suspect i'll get used > to the

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-19 Thread Greg Minshall
Nicolas, thanks. i take it this is a change from (recent?) past behavior? it was kind of nice the old way, but i suspect i'll get used to the new way (no names, just noweb-ref) fairly soon. cheers, Greg

Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-19 Thread Nicolas Goaziou
Hello, Greg Minshall writes: > hi. the description of :noweb-ref says > > When expanding “noweb” style references, the bodies of all code block > with _either_ a block name matching the reference name _or_ a > ‘:noweb-ref’ header argument matching the reference name will be > concatenated