Good day all--

I've been playing with org-babel-detangle and I've noticed somethin= g that's either a bug or a limitation. It's confusing enough that it'= s worth writing down if it's expected. Basically, it doesn't work if = there are variables defined in the begin_src header. I've attached an= example below. The first one won't detangle and the last two will.

* no work

#+begin_src sh sh :t= angle hw.sh :var x=3D"hello world" :shebang #!/bin/sh :comments link

<= div>echo $x

#+end_src

* works

= #+begin_src sh sh :tangle hw2.sh :comments link

echo "helloworld2= "

#+end_src

* stillworks

#+beg= in_src sh sh :tangle hw3.sh :comments link :shebang #!/bin/sh

ech= o "helloworld3"

#= +end_src

I've tested with 9.1.7 and 9.1.14 so if t= his is supposed to be supported it's not something newly broken.

Thx.

--Brad

------=_Part_4259897_2135124753.1538636915100-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Rettke Subject: Re: org-babel-detangle issue on 9.1.14 Date: Thu, 4 Oct 2018 10:19:00 -0500 Message-ID: References: <833272723.4259898.1538636915102.ref@mail.yahoo.com> <833272723.4259898.1538636915102@mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g85PZ-0001j7-BO for emacs-orgmode@gnu.org; Thu, 04 Oct 2018 11:19:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g85PV-0002pY-CL for emacs-orgmode@gnu.org; Thu, 04 Oct 2018 11:19:33 -0400 Received: from mail-lj1-f171.google.com ([209.85.208.171]:34076) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g85PV-0002ok-34 for emacs-orgmode@gnu.org; Thu, 04 Oct 2018 11:19:29 -0400 Received: by mail-lj1-f171.google.com with SMTP id f8-v6so8760810ljk.1 for ; Thu, 04 Oct 2018 08:19:28 -0700 (PDT) In-Reply-To: <833272723.4259898.1538636915102@mail.yahoo.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: bknotwell@yahoo.com Cc: Org-mode On Thu, Oct 4, 2018 at 2:09 AM Brad Knotwell wrote: > I've been playing with org-babel-detangle and I've noticed something that's either a bug or a limitation. It's confusing enough that > it's worth writing down if it's expected. Basically, it doesn't work if there are variables defined in the begin_src header. I've > attached an example below. The first one won't detangle and the last two will. That is expected behavior. Org can only detangle the content of source blocks. It can't deduce how that source code got in there. Maybe this example says it better: #+begin_src sh sh :tangle hw.sh :var x=(random) :shebang #!/bin/sh :comments link echo $x #+end_src Tangles to #!/bin/sh # [[file:~/tmp/test.org::org_gcr_2018-10-04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE][org_gcr_2018-10-04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE]] x='422131055910453451' echo $x # org_gcr_2018-10-04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE ends here From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brad Knotwell Subject: Re: org-babel-detangle issue on 9.1.14 Date: Thu, 4 Oct 2018 15:51:43 +0000 (UTC) Message-ID: <213080806.4531977.1538668303406@mail.yahoo.com> References: <833272723.4259898.1538636915102.ref@mail.yahoo.com> <833272723.4259898.1538636915102@mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4531976_1136934434.1538668303404" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g85ve-000647-Ry for emacs-orgmode@gnu.org; Thu, 04 Oct 2018 11:52:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g85va-0007Md-Dr for emacs-orgmode@gnu.org; Thu, 04 Oct 2018 11:52:42 -0400 Received: from sonic305-20.consmr.mail.gq1.yahoo.com ([98.137.64.83]:34462) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g85va-0007KF-3k for emacs-orgmode@gnu.org; Thu, 04 Oct 2018 11:52:38 -0400 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Grant Rettke Cc: Org-mode ------=_Part_4531976_1136934434.1538668303404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the response. =C2=A0At a minimum, I'd recommend changing the er= ror message from "Not in a source block" to something more descriptive as m= ost people's initial response will be, "uhhh, but it looks like I am." =C2= =A0 Ideally, an additional comment marker would delineate the source block from= the meta-programmed variables to allow the edited source code's verbatim r= eplacement. =C2=A0Or it might make sense to have a setting that separates t= he tangled source file from the meta programmed variables. =C2=A0Using your= example above, it could tangle to something like the following: #!/bin/sh # [[file:~/tmp/test.org::org_gcr_2018-10-04T08-35-43-05-00_cosmicality_CCEA= CAA2-A6B3-4FDD-9259-7F633316F0CE][org_gcr_2018-10-04T08-35-43-05-00_cosmica= lity_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE]]. ./noideahowtonamethesegenerica= lly.sh =C2=A0 =C2=A0# the naming seems tricky to me echo $x# org_gcr_2018-10-04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9= 259-7F633316F0CE ends here If babel was starting anew, I'd prefer that as it seems cleaner than adding= another comment (assumption: majority of languages have an include-like fa= cility of some sort). =C2=A0Given the number of languages currently support= ed, the additional comment delimiters seem less disruptive. --Brad On Thursday, October 4, 2018, 8:19:30 AM PDT, Grant Rettke wrote: =20 =20 On Thu, Oct 4, 2018 at 2:09 AM Brad Knotwell wrote: > I've been playing with org-babel-detangle and I've noticed something that= 's either a bug or a limitation.=C2=A0 It's confusing enough that > it's worth writing down if it's expected.=C2=A0 Basically, it doesn't wor= k if there are variables defined in the begin_src header.=C2=A0 I've > attached an example below.=C2=A0 The first one won't detangle and the las= t two will. That is expected behavior. Org can only detangle the content of source blocks. It can't deduce how that source code got in there. Maybe this example says it better: #+begin_src sh sh :tangle hw.sh :var x=3D(random) :shebang #!/bin/sh :comments link echo $x #+end_src Tangles to #!/bin/sh # [[file:~/tmp/test.org::org_gcr_2018-10-04T08-35-43-05-00_cosmicality_CCEA= CAA2-A6B3-4FDD-9259-7F633316F0CE][org_gcr_2018-10-04T08-35-43-05-00_cosmica= lity_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE]] x=3D'422131055910453451' echo $x # org_gcr_2018-10-04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F6= 33316F0CE ends here =20 ------=_Part_4531976_1136934434.1538668303404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for the response. At a minimum, I'd recommend cha= nging the error message from "Not in a source block" to something more desc= riptive as most people's initial response will be, "uhhh, but it looks like= I am."

Ideally, an additional comment mark= er would delineate the source block from the meta-programmed variables to a= llow the edited source code's verbatim replacement. Or it might make = sense to have a setting that separates the tangled source file from the met= a programmed variables. Using your example above, it could tangle to = something like the following:

#!/bi= n/sh
# [[file:~/tmp/test.org::org_gcr_2018-10-04T08-35-43= -05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE][org_gcr_2018-10-04= T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE]]

. ./noideahowtonamethesegenerically.sh # the nam= ing seems tricky to me
echo $x

# org_gcr_2018-10-= 04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE
ends here

If babel was starting anew, I'= d prefer that as it seems cleaner than adding another comment (assumption: = majority of languages have an include-like facility of some sort). Gi= ven the number of languages currently supported, the additional comment del= imiters seem less disruptive.

--Bra= d

=20

On Thursday, October 4, 2018, 8:19:30 AM PDT, Grant Ret= tke <gcr@wisdomandwonder.com> wrote:

On Thu, Oct 4, 2018 at 2:09 AM Brad K= notwell <bknotwell@yahoo.com> wrote:
> I've been playing with org-babel-detangle and I've noticed s= omething that's either a bug or a limitation. It's confusing enough t= hat
> it's worth writing down if it's expected. = Basically, it doesn't work if there are variables defined in the begin_src = header. I've
> attached an example below. = The first one won't detangle and the last two will.

That is expected behavior. Org can only detangle the content = of source
blocks. It can't deduce how that
source code got in there.

Maybe th= is example says it better:

#+begin_src= sh sh :tangle hw.sh :var x=3D(random) :shebang #!/bin/sh
:comments link
echo $x
#+end_src

Tangles to

#!/bin/sh
# [[file:~/tmp/test.org::org_gcr_2018-10-0= 4T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE][org_gcr_= 2018-10-04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0CE]= ]
x=3D'422131055910453451'

echo $x

# org_gc= r_2018-10-04T08-35-43-05-00_cosmicality_CCEACAA2-A6B3-4FDD-9259-7F633316F0C= E
ends here