Re: Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]

[tsd@tsdye.com (Thomas S. Dye)]

Eric Schulte <schulte.eric@gmail.com> writes:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> András Major <andras.g.major@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