Eric Schulte <schulte.e...@gmail.com> writes: > Nick Dokos <nicholas.do...@hp.com> writes: > >> András Major <andras.g.ma...@gmail.com> wrote: >> >>> Hi Eric, >>> >>> > > Your file uses #+data: where I use #+tblname: -- which one is the >>> > > official one? I have the impression that it's #+data:, but I haven't >>> > > come across that in the manual or elsewhere before. If #+tblname: >>> > > isn't supposed to be used as a target for a variable in the code >>> > > block, then we should make sure that it *never* behaves as such. >>> > > >>> > >>> > In the interest of backwards compatibility and convenience there are a >>> > number of equivalent options here, see the value of the >>> > `org-babel-data-names' variable for all possible names. >>> >>> OK, in that case the example still doesn't work for me. Whether I use >>> #+data or #+tblname, specifying the :noexport: tag in the section >>> containing the table causes the HTML export to report the error >>> "reference 'table1' not found in this buffer". >>> >>> As Bastien pointed out earlier, I'm not talking about simple >>> evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so >>> far). >>> >> > > Are you /sure/ that this doesn't work for you? On my system C-c C-e A > in the following attached org-mode file (posted earlier in this thread) > > * top > ** not to be exported :noexport: > #+data: something > | 0 | > | 1 | > | 1 | > | 2 | > | 3 | > | 5 | > | 8 |
Hi Eric, Your example works here, too. It fails, however, if there is an empty line between #+data: something and the first row of the table. Then a listp, nil error is raised. Perhaps this is what Andras is seeing? I haven't gone back to take a specific look at the manual, but in the past I've thought that the documentation of table naming isn't as good as it might be. In fact, I often have a hard time finding it in the first place :) hth, Tom > > ** to be exported > #+begin_src emacs-lisp :var fib=something :exports results > (car (nth 4 fib)) > #+end_src > > > Does export and correctly resolves the variable in the :noexport:'d > section resulting in the following output. > > ,---- > | noexport > | ======== > | > | Author: Eric Schulte > | Date: 2011-08-23 17:37:28 MDT > | > | > | Table of Contents > | ================= > | 1 top > | 1.1 to be exported > | > | > | 1 top > | ------ > | > | 1.1 to be exported > | =================== > | > | > | 3 > | > `---- > >> >> This is probably caused by org-export-preprocess-string: it does things >> in a certain order, and it probably kills the :noexport: stuff before it >> gets to the evaluation of the source block. >> >> It might be possible to change the order (ISTR a couple of cases, where >> behavior was changed by doing exactly this), but it's probably fraught with >> peril: approach with caution. >> > > The above analysis is correct. Babel has to deal with this when > resolving header arguments, noweb references and variable expansions. > It does this by resolving these things in the original org-mode buffer > rather than in the temporary export buffer which is often missing > portions which are not to be exported. See the definition of the > `org-babel-exp-in-export-file' macro for details. > > Best -- Eric > >> >> Nick >> >> PS. Warning: the above is a guess: it may have nothing to do with reality. >> -- Thomas S. Dye http://www.tsdye.com