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

[Eric Schulte <schulte.eric@gmail.com>]

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

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)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: noexport.org --]
[-- Type: text/x-org, Size: 252 bytes --]

* top
** not to be exported                                              :noexport:
#+data: something
| 0 |
| 1 |
| 1 |
| 2 |
| 3 |
| 5 |
| 8 |

** to be exported
#+begin_src emacs-lisp :var fib=something :exports results
  (car (nth 4 fib))
#+end_src

[-- Attachment #3: Type: text/plain, Size: 1359 bytes --]


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.
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/