From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id LlAUEGd7nV+tXAAA0tVLHw (envelope-from ) for ; Sat, 31 Oct 2020 14:57:43 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id UJJYC2d7nV++SwAAbx9fmQ (envelope-from ) for ; Sat, 31 Oct 2020 14:57:43 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CE04894051B for ; Sat, 31 Oct 2020 14:57:40 +0000 (UTC) Received: from localhost ([::1]:53788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYsK2-0007J0-9L for larch@yhetil.org; Sat, 31 Oct 2020 10:57:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34044) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYsJM-0007IJ-7j for emacs-orgmode@gnu.org; Sat, 31 Oct 2020 10:56:56 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:46495) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYsJJ-0004oj-Bg for emacs-orgmode@gnu.org; Sat, 31 Oct 2020 10:56:55 -0400 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id DFA75B79; Sat, 31 Oct 2020 10:56:49 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute7.internal (MEProxy); Sat, 31 Oct 2020 10:56:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=0PSn1FBs10Yay8+SEXmeqIxf0iUwPtt kkHBoagA7apY=; b=l0rMGrgZDIeA4asmHbbmDoJHCZJSkin5YsUZuCoRUNwDkZk 4y5LGfG5CD0BN843ec97dvYi0eyoFFyd+ktUhxEOp66UkhtE6y4O7HFDGjIwueju XTfalrzOLHGpYyDmKhpAzcO6fwb9wtx1whyDExfd6WPPvYbQqGGw9rXdlYyzjTh7 RLn6YKpjSeYUWf5tfE8/OXHcFrvHw+kvsdleqZmW0cu1fkRBep/exyHGeqBv7C/0 1fXREDHj9FOh2nHxXzZDGe5QW5RjTRIb3d9ZtP7+ZbQP7P+BrwunqZxjegjoO6eR ONDadVkOMsZCvGr1pOFFO9WEpkj1kLoIo2lz8lQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0PSn1F Bs10Yay8+SEXmeqIxf0iUwPttkkHBoagA7apY=; b=DB53tMObkvYHu07dCkvb0L C8W9lwEBCNIRKWC8cj0LQ3J6mSCMxD7oVL45G0aHccJXP0j5wFSoQY20jw8//tBd XnNAzqEWc9SGTrgcjy19G3WPVJN2OdkQEl5XdDKShzy23Ue291Po5qXn+lfiRnPu bhXrT6AoJlkTbkQzNoxuCY3vdFsbEDAlRbrChXsGsWN4Aoc8+5d0EyVPtW6kpeT3 8y5fMkYlUIWWZiEyF7wSDUnpnpzXZOBHiB7g9uaN2vgPFjmCcKKKwON318/VkQjo Bs45tg2zLPwPBIEMkR42Jkx6s8KuJwkiY2KVU3/OSSy3WjvYBLJeb62C751x77og == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleejgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesmhdtre erreerjeenucfhrhhomhepfdflrghmvghsuceuohihlhgvfdcuoehjsghohihlvgesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpedthedugeevhfekvdfhudfhte ffieegjeekuedtueffjefhfedtleeitefgueetfeenucffohhmrghinhepmhgrnhhurghl rdhorhhgpdhorhhgmhhouggvrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepjhgsohihlhgvsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 216CD6680078; Sat, 31 Oct 2020 10:56:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: <295ebc4d-a87d-4a28-9365-188f2754c85d@www.fastmail.com> In-Reply-To: References: <50a71862-dbde-41c1-aab8-b7570d9c5d3c@www.fastmail.com> Date: Sat, 31 Oct 2020 10:56:28 -0400 From: "James Boyle" To: "Tom Gillespie" Subject: =?UTF-8?Q?Re:_Is_reading_nested_simple_lists_into_org-babel_code_blocks_?= =?UTF-8?Q?currently_supported=3F_[PATCH]_-_manual.org?= Content-Type: multipart/mixed; boundary=dc45e5434f524fde8ee5fbaafdbb994a Received-SPF: pass client-ip=64.147.123.21; envelope-from=jboyle@fastmail.com; helo=wout5-smtp.messagingengine.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/31 10:56:50 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=fastmail.com header.s=fm1 header.b=l0rMGrgZ; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=DB53tMOb; dmarc=pass (policy=none) header.from=fastmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: 0.50 X-TUID: WZNV8jG5bFij --dc45e5434f524fde8ee5fbaafdbb994a Content-Type: multipart/alternative; boundary=d848ee06c8b64debbbdd70f770461af4 --d848ee06c8b64debbbdd70f770461af4 Content-Type: text/plain Hi Tom (orgmode list cc'ed), > As a result > each ob-lang will probably have to deal with this itself, or at least > they will have to define how to consume quoted elisp lists without > raising errors. Thanks -- this is exactly the judgment check I was looking for -- if this type of support should fall on individual languages or not. To this end, I've attached a TINYCHANGE patch for manual.org that would have helped me in my confusion. The change updates the example to reflect the current state of the output, and clarifies the level of support. Thanks for any help you can provide. James On Thu, Oct 29, 2020, at 12:52 PM, Tom Gillespie wrote: > Hi James, > I would file this along with other ob-lang dependent features such > as TRAMP remote execution support. For example, python works as in > your other examples, but only if you define :var unordered="unordered" > as another variable before the variable you pass the plain list to > because python tries to dereference the symbol. A global solution like > the one you propose breaks the semantics in cases where a language > does correctly deal with quoted lists (e.g. common lisp). As a result > each ob-lang will probably have to deal with this itself, or at least > they will have to define how to consume quoted elisp lists without > raising errors. That said, I'm not sure that org babel requires that > ob-lang implementations handle this. Maybe it should? I've added this > to my growing list of issues related to org babel regularization. > Best! > Tom > > On Thu, Oct 29, 2020 at 7:25 AM James Boyle wrote: > > > > Hi all, > > > > Since this is a bit of a long post, I've put my questions and summary > > comment at the top, with the detailed context below. > > > > 1. What is the level of support for reading nested simple lists into > > org-babel code blocks? > > 2. When the manual (see link below) says that they are not supported, > > is it known if it meant "not at all supported," or, that support is > > currently language-dependent? > > 3. Directionally, does the org-mode project care to support nested > > simple lists? > > > > I'm happy to submit patches for both code and manual in any event, but > > wanted to align on if there are goals for supporting reading nested > > lists, and if so, at what level. > > > > At a minimum, I think updating the manual to be more precise would be > > great. > > > > Thanks for your any assistance you can provide. > > > > Details: > > > > I was going through the manual on this page: > > > > https://orgmode.org/manual/Environment-of-a-Code-Block.html#Environment-of-a-Code-Block > > > > and testing out the example, "A simple named list." > > > > Contrary to this line in the manual: > > > > > Note that only the top level list items are passed along. Nested list items are ignored. > > > > It looks like the example org-babel block *does* work for nested > > lists, depending upon the language. I am using org-mode 9.4. > > > > Here is the org block verbatim from the manual, with the > > results that are supposed to occur: > > > > #+NAME: example-list > > - simple > > - not > > - nested > > - list > > > > #+BEGIN_SRC emacs-lisp :var x=example-list > > (print x) > > #+END_SRC > > > > #+RESULTS: > > | simple | list | > > > > > > And here is the same block, when I evaluate it locally, with the > > actual results, showing that unordered, nested lists are not ignored. > > > > #+NAME: example-list > > - simple > > - not > > - nested > > - list > > > > #+BEGIN_SRC emacs-lisp :var x=example-list > > (print x) > > #+END_SRC > > > > #+RESULTS: > > | simple | (unordered (not) (nested)) | > > | list | | > > > > > > I thought this was a nice surprise, until I noticed that whether or > > not it works is language-dependent. > > > > In ruby, I get an error: > > > > #+begin_src ruby :var x=example-list > > # This is the error I get: > > > > # `main': undefined local variable or method `unordered' for > > # main:Object (NameError) > > puts x > > #+end_src > > > > #+RESULTS: > > > > And here is the equivalent error in js. Presumably other languages > > have variable support for this feature. > > > > #+begin_src js :var x=example-list > > // Below is a partial error trace: > > > > // /private/var/folders/mc/jylgk04j5r1f96hcsd3ywm8h0000gn/T/babel-shSmEq/js-script-xzngmd:2 > > // var x=[["simple", [unordered, ["not"], ["nested"]]], ["list"]]; ^ > > // ReferenceError: unordered is not defined > > return x > > #+end_src > > > > #+RESULTS: > > > > The error can be trivially "fixed" by some code like this, or making > > the equivalent change in the actual source line to output a string > > rather than a symbol. Changing L#2365 linked below to use "unordered" > > (string) rather than 'unordered (symbol) seemed to fix it, and > > produced no new test failures for me. > > > > #+begin_src emacs-lisp > > ; See this line for where 'unordered is being spat out: > > ; https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-core.el#L2365 > > (defun patch-get-vars-output (vars) > > "Substitute special Lisp symbols with a Lisp keyword. > > This allows Ruby to not barf on an undefined variable error > > for certain input structures like nested lists. > > Argument VARS is a tree structure. See above example format." > > (subst "unordered" 'unordered vars)) > > > > (advice-add 'org-babel--get-vars :filter-return #'patch-get-vars-output) > > #+end_src > > > > Thanks again for any help or direction you can provide. > > > > James Boyle > > > --d848ee06c8b64debbbdd70f770461af4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Tom (or= gmode list cc'ed),

> As a result
> each ob-lang will probably have to deal with this itsel= f, or at least
> they will have to define how to consum= e quoted elisp lists without
> raising errors.

Thanks -- this is exactly the judgment check I was= looking for -- if this type of support should fall on individual langua= ges
or not.

To this end, I'v= e attached a TINYCHANGE patch for manual.org that would have helped me i= n my confusion. The change updates the example to reflect the current st= ate of the output, and clarifies the level of support.
Thanks for any help you can provide.

James

On Thu, Oct 29, 2020, at 12:52 PM, = Tom Gillespie wrote:
Hi James,
    I would file this alo= ng with other ob-lang dependent features such
as TRAMP rem= ote execution support. For example, python works as in
you= r other examples, but only if you define :var unordered=3D"unordered"
as another variable before the variable you pass the plain l= ist to
because python tries to dereference the symbol. A g= lobal solution like
the one you propose breaks the semanti= cs in cases where a language
does correctly deal with quot= ed lists (e.g. common lisp). As a result
each ob-lang will= probably have to deal with this itself, or at least
they = will have to define how to consume quoted elisp lists without
<= div>raising errors. That said, I'm not sure that org babel requires that=
ob-lang implementations handle this. Maybe it should? I'v= e added this
to my growing list of issues related to org b= abel regularization.
Best!
Tom

On Thu, Oct 29, 2020 at 7:25 AM James Boyle <jboyle@fastmail.com> wrote:
>
> Hi all,
>
&= gt; Since this is a bit of a long post, I've put my questions and summar= y
> comment at the top, with the detailed context below= .
>
> 1. What is the level of support = for reading nested simple lists into
>   = ; org-babel code blocks?
> 2. When the manual (see link= below) says that they are not supported,
>  =   is it known if it meant "not at all supported," or, that support = is
>    currently language-dependent?
> 3. Directionally, does the org-mode project care to sup= port nested
>    simple lists?
=
>
> I'm happy to submit patches for both code a= nd manual in any event, but
> wanted to align on if the= re are goals for supporting reading nested
> lists, and= if so, at what level.
>
> At a minimu= m, I think updating the manual to be more precise would be
> great.
>
> Thanks for your any a= ssistance you can provide.
>
> Details= :
>
> I was going through the manual o= n this page:
>
>
> an= d testing out the example, "A simple named list."
>
=
> Contrary to this line in the manual:
><= br>
> > Note that only the top level list items are pass= ed along. Nested list items are ignored.
>
> It looks like the example org-babel block *does* work for nested<= br>
> lists, depending upon the language. I am using org-mo= de 9.4.
>
> Here is the org block verb= atim from the manual, with the
> results that are suppo= sed to occur:
>
> #+NAME: example-list=
> - simple
>   - not
>   - nested
> - list
>
> #+BEGIN_SRC emacs-lisp :var x=3Dexample-list
>   (print x)
> #+END_SRC
=
>
> #+RESULTS:
> | simpl= e | list |
>
>
> And = here is the same block, when I evaluate it locally, with the
> actual results, showing that unordered, nested lists are not ign= ored.
>
> #+NAME: example-list
> - simple
>   - not
= >   - nested
> - list
>
> #+BEGIN_SRC emacs-lisp :var x=3Dexample-list
=
>   (print x)
> #+END_SRC
>
> #+RESULTS:
> | simple | (uno= rdered (not) (nested)) |
> | list   | &n= bsp;           &n= bsp;           &n= bsp;  |
>
>
> I = thought this was a nice surprise, until I noticed that whether or
> not it works is language-dependent.
>
<= /div>
> In ruby, I get an error:
>
> #+begin_src ruby :var x=3Dexample-list
> &nb= sp; # This is the error I get:
>
>&nbs= p;  # `main': undefined local variable or method `unordered' for
>   # main:Object (NameError)
>= ;   puts x
> #+end_src
>
=
> #+RESULTS:
>
> And her= e is the equivalent error in js. Presumably other languages
> have variable support for this feature.
>
> #+begin_src js :var x=3Dexample-list
>&nbs= p;  // Below is a partial error trace:
>
=
>   // /private/var/folders/mc/jylgk04j5r1f96hcsd3ywm8= h0000gn/T/babel-shSmEq/js-script-xzngmd:2
>  = // var x=3D[["simple", [unordered, ["not"], ["nested"]]], ["list"]]; ^<= br>
>   // ReferenceError: unordered is not defin= ed
>   return x
> #+end_src<= br>
>
> #+RESULTS:
>
<= /div>
> The error can be trivially "fixed" by some code like this= , or making
> the equivalent change in the actual sourc= e line to output a string
> rather than a symbol. Chang= ing L#2365 linked below to use "unordered"
> (string) r= ather than 'unordered (symbol) seemed to fix it, and
> = produced no new test failures for me.
>
&= gt; #+begin_src emacs-lisp
>   ; See this lin= e for where 'unordered is being spat out:
>   (defun patch-get-va= rs-output (vars)
>     "Substitute = special Lisp symbols with a Lisp keyword.
>  = This allows Ruby to not barf on an undefined variable error
>   for certain input structures like nested lists.
<= /div>
>   Argument VARS is a tree structure.  See = above example format."
>     (subst= "unordered" 'unordered vars))
>
>&nbs= p;  (advice-add 'org-babel--get-vars :filter-return #'patch-get-var= s-output)
> #+end_src
>
= > Thanks again for any help or direction you can provide.
>
> James Boyle
>
=

--d848ee06c8b64debbbdd70f770461af4-- --dc45e5434f524fde8ee5fbaafdbb994a Content-Disposition: attachment;filename="0001-org-manual.org-Clarify-org-babel-nested-list-support.patch" Content-Type: application/octet-stream; name="0001-org-manual.org-Clarify-org-babel-nested-list-support.patch" Content-Transfer-Encoding: BASE64 RnJvbSA3NDVkZTI5MjdhOTYxOWVmZmJkMzU2OTlhNzRiODhhMzk5ZTcxNTFhIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKYW1lcyBCb3lsZSA8amhoYm95bGVAZ21haWwuY29t PgpEYXRlOiBGcmksIDMwIE9jdCAyMDIwIDE1OjAzOjEyIC0wNDAwClN1YmplY3Q6IFtQQVRD SF0gb3JnLW1hbnVhbC5vcmc6IENsYXJpZnkgb3JnLWJhYmVsIG5lc3RlZCBsaXN0IHN1cHBv cnQKCiogZG9jL29yZy1tYW51YWwub3JnIChFbnZpcm9ubWVudCBvZiBhIGNvZGUgYmxvY2sp OiBDbGFyaWZ5CnRoZSBiZWhhdmlvciBmb3IgbmVzdGVkIGxpc3RzIGluIG9yZy1iYWJlbCBj b2RlIGJsb2NrcwotLS0KIGRvYy9vcmctbWFudWFsLm9yZyB8IDggKysrKystLS0KIDEgZmls ZSBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0 IGEvZG9jL29yZy1tYW51YWwub3JnIGIvZG9jL29yZy1tYW51YWwub3JnCmluZGV4IGVmMmRh ZDllZi4uZDZiZmVlZjZhIDEwMDY0NAotLS0gYS9kb2Mvb3JnLW1hbnVhbC5vcmcKKysrIGIv ZG9jL29yZy1tYW51YWwub3JnCkBAIC0xNjgyNCwxMSArMTY4MjQsMTMgQEAgSGVyZSBhcmUg ZXhhbXBsZXMgb2YgcGFzc2luZyB2YWx1ZXMgYnkgcmVmZXJlbmNlOgogICAsIytFTkRfU1JD CiAKICAgLCMrUkVTVUxUUzoKLSAgfCBzaW1wbGUgfCBsaXN0IHwKKyAgfCBzaW1wbGUgfCAo dW5vcmRlcmVkIChub3QpIChuZXN0ZWQpKSB8CisgIHwgbGlzdCAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAjK2VuZF9leGFtcGxlCiAKLSAgTm90ZSB0aGF0IG9ubHkg dGhlIHRvcCBsZXZlbCBsaXN0IGl0ZW1zIGFyZSBwYXNzZWQgYWxvbmcuICBOZXN0ZWQKLSAg bGlzdCBpdGVtcyBhcmUgaWdub3JlZC4KKyAgTm90ZSB0aGF0IHRoZSBuZXN0ZWQgbGlzdCBp dGVtcyBhcmUgcGFzc2VkIGFsb25nLCBhbG9uZyB3aXRoIHRoZQorICBsaXN0IHR5cGUgb2Yg dGhlIGZpcnN0IGVsZW1lbnQgb2YgdGhlIG5lc3RlZCBsaXN0LiBTdXBwb3J0IGZvcgorICBu ZXN0ZWQgbGlzdHMgY2FuIHZhcnkgYnkgc291cmNlIGxhbmd1YWdlLgogCiAtIGNvZGUgYmxv Y2sgd2l0aG91dCBhcmd1bWVudHMgOjoKIAotLSAKMi4yOC4wCgo= --dc45e5434f524fde8ee5fbaafdbb994a--