Org Babel resolution of `:var` value reference inconsistent

Org Babel resolution of `:var` value reference inconsistent

[myq]

Sometime since Org version 8.3beta and now, the way Org Babel resolves
the value of the `:var` header argument when assigned to a reference has
changed.

Previously, the following would work when exporting:

--8<---------------cut here---------------start------------->8---
* test

#+BEGIN_SRC R :var dat=table-data
  print(summary(dat));
#+END_SRC

** COMMENT

#+TBLNAME: table-data
| number | measurement |
|--------+-------------|
| 1      | 10          |
--8<---------------cut here---------------end--------------->8---

The above /still/ works when manually evaluating the block (C-c C-c whil
in the block), but when exporting, the following error is thrown:
`org-babel-ref-resolve: Reference `table-data' not found in this buffer`

Curiously, the following tweak works for both manual evaluation and for
exporting and produces the same results that the above file used to
produce:

--8<---------------cut here---------------start------------->8---
#+OPTIONS: inline:nil
* test

#+BEGIN_SRC R :var dat=table-data
  print(summary(dat));
#+END_SRC

*************** test
#+TBLNAME: table-data
| number | measurement |
|--------+-------------|
| 1      | 10          |
*************** END
--8<---------------cut here---------------end--------------->8---

This seems to be a bug, but perhaps there is a reason for this new
behaviour?

Thank you in advance for any insights.

Re: Org Babel resolution of `:var` value reference inconsistent

[Andreas Leha]

Hi myq,

myq <myqlarson@gmail.com> writes:
> Sometime since Org version 8.3beta and now, the way Org Babel resolves
> the value of the `:var` header argument when assigned to a reference has
> changed.
>
> Previously, the following would work when exporting:
>
> * test
>
> #+BEGIN_SRC R :var dat=table-data
>   print(summary(dat));
> #+END_SRC
>
> ** COMMENT
>
> #+TBLNAME: table-data
> | number | measurement |
> |--------+-------------|
> | 1      | 10          |
>
>
> The above /still/ works when manually evaluating the block (C-c C-c whil
> in the block), but when exporting, the following error is thrown:
> `org-babel-ref-resolve: Reference `table-data' not found in this buffer`
>
> Curiously, the following tweak works for both manual evaluation and for
> exporting and produces the same results that the above file used to
> produce:
>
> #+OPTIONS: inline:nil
> * test
>
> #+BEGIN_SRC R :var dat=table-data
>   print(summary(dat));
> #+END_SRC
>
> *************** test
> #+TBLNAME: table-data
> | number | measurement |
> |--------+-------------|
> | 1      | 10          |
> *************** END
>
> This seems to be a bug, but perhaps there is a reason for this new
> behaviour?
>
> Thank you in advance for any insights.

There are two ways to exclude subtrees from export: the COMMENT keyword
and the :noexport: tag.  I think what you want to use here is the
:noexport: tag.

Here is the difference:

- COMMENTing a subtree is meant to be (roughly?) the same as putting '# '
  at the beginning of all the lines from that region.

- The :noexport: tag will simply skip the region from export.

So, to me it is more surprising that the manual execution works.  For
instance, I might have two tables with the same name.  Then, COMMENTing
one of them should ensure that the other one is used.

HTH,
Andreas

Re: Org Babel resolution of `:var` value reference inconsistent

[Nick Dokos]

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> ...
> So, to me it is more surprising that the manual execution works.  For
> instance, I might have two tables with the same name.  Then, COMMENTing
> one of them should ensure that the other one is used.
>

COMMENT works during export *only* I believe. You have to explicitly
comment out one of the tables otherwise. If there are two tables with
the same name, babel will use the one nearer the beginning of the file
and ignore the second one (I determined this experimentally, *not* by
reading and understanding the code - ymmv).

-- 
Nick

Re: Org Babel resolution of `:var` value reference inconsistent

[Andreas Leha]

Hi Nick,

Nick Dokos <ndokos@gmail.com> writes:
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> ...
>> So, to me it is more surprising that the manual execution works.  For
>> instance, I might have two tables with the same name.  Then, COMMENTing
>> one of them should ensure that the other one is used.
>>
>
> COMMENT works during export *only* I believe. You have to explicitly
> comment out one of the tables otherwise. If there are two tables with
> the same name, babel will use the one nearer the beginning of the file
> and ignore the second one (I determined this experimentally, *not* by
> reading and understanding the code - ymmv).

Thanks for following up on this.  I also ran some tests now and confirm
what you see.  Test code below [2].

I'd say it is a bug if the results from evaluation differ between
manual evaluation and during export.

And even if it is not explicitely contradicting the manual [1] (which
does not say anything about finding references), I'd prefer if
references in COMMENT'ed sections are not found -- neither during export
nor during evaluation.  This would be more inline with my intuition of
COMMENT is equivalent to # (which is also suggested by the fact that
COMMENT is described in the section on #).


Regards,
Andreas

[1] http://orgmode.org/manual/Comment-lines.html#Comment-lines


[2] Test code
--8<---------------cut here---------------start------------->8---
* Test COMMENTing babel reference

** COMMENT Table 1
#+name: testtable
| a | b |
|---+---|
| 1 | 2 |


# ** Table 2
# #+name: testtable
# | c | d |
# |---+---|
# | 3 | 4 |


# ** Table 2.5
# #+name: testtable2
# | c | d |
# |---+---|
# | 3 | 4 |



** Table 3
#+name: testtable
| e | f |
|---+---|
| 5 | 6 |


** Use (one of) the visible tables
This gives different results during export compared to manual
evaluation.
#+begin_src R :var tab=testtable :colnames yes :exports results
  tab
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |

** Use the #'ed table						   :noexport:
This works neither during export nor during manual evaluation.
#+begin_src R :var tab=testtable2 :colnames yes :exports results
  tab
#+end_src
--8<---------------cut here---------------end--------------->8---

Re: Org Babel resolution of `:var` value reference inconsistent

[Martin Carlé]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]


On 2015-11-04 Wed 14:14, Andreas Leha wrote:

> ,---------------------------------------------------------------------------
> | > I'd say it is a bug if the results from evaluation differ between
> | > manual evaluation and during export.
> | >
> | > And even if it is not explicitely contradicting the manual [1] (which
> | > does not say anything about finding references), I'd prefer if
> | > references in COMMENT'ed sections are not found -- neither during export
> | > nor during evaluation.  This would be more inline with my intuition of
> | > COMMENT is equivalent to # (which is also suggested by the fact that
> | > COMMENT is described in the section on #).
> `---------------------------------------------------------------------------

I'd like to strongly support this view.

Regards,
mc

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 805 bytes --]

Re: Org Babel resolution of `:var` value reference inconsistent

[Nicolas Goaziou]

Hello,

Martin Carlé <mc@aiguphonie.com> writes:

> On 2015-11-04 Wed 14:14, Andreas Leha wrote:
>
>> ,---------------------------------------------------------------------------
>> | > I'd say it is a bug if the results from evaluation differ between
>> | > manual evaluation and during export.
>> | >
>> | > And even if it is not explicitely contradicting the manual [1] (which
>> | > does not say anything about finding references), I'd prefer if
>> | > references in COMMENT'ed sections are not found -- neither during export
>> | > nor during evaluation.  This would be more inline with my intuition of
>> | > COMMENT is equivalent to # (which is also suggested by the fact that
>> | > COMMENT is described in the section on #).
>> `---------------------------------------------------------------------------
>
> I'd like to strongly support this view.

Fixed, in master (02c78501472fba94f8cf5a3d218b5c8845b28827).

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: Org Babel resolution of `:var` value reference inconsistent

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Martin Carlé <mc@aiguphonie.com> writes:
>
>> On 2015-11-04 Wed 14:14, Andreas Leha wrote:
>>
>>> ,---------------------------------------------------------------------------
>>> | > I'd say it is a bug if the results from evaluation differ between
>>> | > manual evaluation and during export.
>>> | >
>>> | > And even if it is not explicitely contradicting the manual [1] (which
>>> | > does not say anything about finding references), I'd prefer if
>>> | > references in COMMENT'ed sections are not found -- neither during export
>>> | > nor during evaluation.  This would be more inline with my intuition of
>>> | > COMMENT is equivalent to # (which is also suggested by the fact that
>>> | > COMMENT is described in the section on #).
>>> `---------------------------------------------------------------------------
>>
>> I'd like to strongly support this view.
>
> Fixed, in master (02c78501472fba94f8cf5a3d218b5c8845b28827).
>
> Thank you.
>

Thank you.

Regards,
Andreas