* Org Babel resolution of `:var` value reference inconsistent
@ 2015-11-02 7:40 myq
2015-11-02 9:01 ` Andreas Leha
0 siblings, 1 reply; 7+ messages in thread
From: myq @ 2015-11-02 7:40 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Org Babel resolution of `:var` value reference inconsistent
2015-11-02 7:40 Org Babel resolution of `:var` value reference inconsistent myq
@ 2015-11-02 9:01 ` Andreas Leha
2015-11-02 13:19 ` Nick Dokos
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Leha @ 2015-11-02 9:01 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Org Babel resolution of `:var` value reference inconsistent
2015-11-02 9:01 ` Andreas Leha
@ 2015-11-02 13:19 ` Nick Dokos
2015-11-04 12:14 ` Andreas Leha
0 siblings, 1 reply; 7+ messages in thread
From: Nick Dokos @ 2015-11-02 13:19 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Org Babel resolution of `:var` value reference inconsistent
2015-11-02 13:19 ` Nick Dokos
@ 2015-11-04 12:14 ` Andreas Leha
2015-11-05 12:56 ` Martin Carlé
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Leha @ 2015-11-04 12:14 UTC (permalink / raw)
To: emacs-orgmode
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---
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Org Babel resolution of `:var` value reference inconsistent
2015-11-04 12:14 ` Andreas Leha
@ 2015-11-05 12:56 ` Martin Carlé
2015-11-05 14:48 ` Nicolas Goaziou
0 siblings, 1 reply; 7+ messages in thread
From: Martin Carlé @ 2015-11-05 12:56 UTC (permalink / raw)
To: Andreas Leha; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Org Babel resolution of `:var` value reference inconsistent
2015-11-05 12:56 ` Martin Carlé
@ 2015-11-05 14:48 ` Nicolas Goaziou
2015-11-05 20:53 ` Andreas Leha
0 siblings, 1 reply; 7+ messages in thread
From: Nicolas Goaziou @ 2015-11-05 14:48 UTC (permalink / raw)
To: Martin Carlé; +Cc: Andreas Leha, emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Org Babel resolution of `:var` value reference inconsistent
2015-11-05 14:48 ` Nicolas Goaziou
@ 2015-11-05 20:53 ` Andreas Leha
0 siblings, 0 replies; 7+ messages in thread
From: Andreas Leha @ 2015-11-05 20:53 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-11-05 20:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-02 7:40 Org Babel resolution of `:var` value reference inconsistent myq
2015-11-02 9:01 ` Andreas Leha
2015-11-02 13:19 ` Nick Dokos
2015-11-04 12:14 ` Andreas Leha
2015-11-05 12:56 ` Martin Carlé
2015-11-05 14:48 ` Nicolas Goaziou
2015-11-05 20:53 ` Andreas Leha
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).