emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lin


From: Nick Dokos
Subject: Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Date: Fri, 21 Oct 2011 14:09:44 -0400

Eric Schulte <address@hidden> wrote:

> >
> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> > could make a substantive difference in some applications. The 
> > following will work:
> >
> >    #+BABEL: :var euro=1.3791 :var salestax=.15
> >
> > The following will not, since it tries to set the same property:
> >
> >    #+PROPERTY: var euro=1.3791
> >    #+PROPERTY: var salestax=.15
> >
> > If BABEL is dropped for PROPERTY, it would be good for the :var: 
> > property to support multiple arguments (comma-separated would be good 
> > for consistency with passing arguments through the SRCNAME). E.g.:
> >
> >    #+PROPERTY: var euro=1.3791, salestax=.15
> >
> > I think I'd like this better in any case.
> >
> 
> Nice idea.  This same issue with "var" arose when we first started
> allowing header arguments to be specified inside subtree properties.
> I've just implemented your suggestion so the following are now possible.
> 
> #+PROPERTY: var foo=1, bar=2
> #+PROPERTY: cache yes
> #+begin_src emacs-lisp
>   (+ foo bar)
> #+end_src
> 
> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> : 3
> 
> and
> 
> #+begin_src emacs-lisp :var foo="this", bar="that"
>   (concat foo " " bar)
> #+end_src
> 
> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> : this that
> 
> Thanks for the suggestion and I hope the above is a sufficient
> replacement for the now-missing #+BABEL: syntax.
> 

Just to clarify my understanding: on a #+PROPERTY line, you *have* to
say

#+PROPERTY: var a=1, b=2

but in the code block itself, you can say *either*

#+begin_src emacs-lisp :var a=1, b=2
...


*or*

#+begin_src emacs-lisp :var a=1 :var b=2
...

Experimentally, both of these currently work: do you have any plans to
outlaw the last form?

Also, how does the comma-separated list of variable assignments interact
with a language where comma has syntactic significance? I was primarily
thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal
construct. AFAICT, that never worked in babel[fn:1], so it may not
matter much, but it may be a good idea to come up with a quoting
mechanism so things like that can be added in the future if necessary.

Thanks,
Nick

Footnotes:

[fn:1] I checked in 7.7 to avoid the recent churn with the following
code block


#+begin_src python :var a='(1,2)'
len(a)
#+end_src

and I get 

,----
|   File "<stdin>", line 3
|     a=[1, [\,, 2]]
|                  ^
| SyntaxError: unexpected character after line continuation character
`----

in the org babel error output buffer.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]