Re: [O] Org Babel resolution of `:var` value reference inconsistent
Hi Nicolas, Nicolas Goaziou writes: > Hello, > > Martin Carlé 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
Re: [O] Org Babel resolution of `:var` value reference inconsistent
Hello, Martin Carlé 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: [O] Org Babel resolution of `:var` value reference inconsistent
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 smime.p7s Description: S/MIME cryptographic signature
Re: [O] Org Babel resolution of `:var` value reference inconsistent
Hi Nick, Nick Dokos writes: > Andreas Leha 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: [O] Org Babel resolution of `:var` value reference inconsistent
Andreas Leha 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: [O] Org Babel resolution of `:var` value reference inconsistent
Hi myq, myq 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
[O] Org Babel resolution of `:var` value reference inconsistent
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.