From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)] Date: Tue, 23 Aug 2011 17:44:03 -0600 Message-ID: <87fwkrpubg.fsf@gmail.com> References: <87pqjwfb0b.fsf@gmail.com> <87bovgf7tc.fsf@gmail.com> <87zkj0cad9.fsf@gmail.com> <6488.1314140595@alphaville.americas.hpqcorp.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([140.186.70.92]:47235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qw0dh-0007mC-8F for emacs-orgmode@gnu.org; Tue, 23 Aug 2011 19:44:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qw0df-0007q2-Kr for emacs-orgmode@gnu.org; Tue, 23 Aug 2011 19:44:13 -0400 Received: from mail-gy0-f169.google.com ([209.85.160.169]:35560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qw0df-0007pv-Cl for emacs-orgmode@gnu.org; Tue, 23 Aug 2011 19:44:11 -0400 Received: by gyg10 with SMTP id 10so545357gyg.0 for ; Tue, 23 Aug 2011 16:44:10 -0700 (PDT) In-Reply-To: <6488.1314140595@alphaville.americas.hpqcorp.net> (Nick Dokos's message of "Tue, 23 Aug 2011 19:03:15 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com Cc: =?utf-8?b?QW5kcsOhcw==?= Major , emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Nick Dokos writes: > Andr=C3=A1s Major wrote: > >> Hi Eric, >>=20 >> > > 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. >> > > >> >=20 >> > 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. >>=20 >> 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". >>=20 >> As Bastien pointed out earlier, I'm not talking about simple >> evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so >> far). >>=20 > 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) --=-=-= Content-Type: text/x-org Content-Disposition: inline; filename=noexport.org * 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 --=-=-= Content-Type: text/plain 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/ --=-=-=--