From mboxrd@z Thu Jan 1 00:00:00 1970 From: tsd@tsdye.com (Thomas S. Dye) 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 14:14:15 -1000 Message-ID: References: <87pqjwfb0b.fsf@gmail.com> <87bovgf7tc.fsf@gmail.com> <87zkj0cad9.fsf@gmail.com> <6488.1314140595@alphaville.americas.hpqcorp.net> <87fwkrpubg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:37246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qw172-0005Sb-Dq for emacs-orgmode@gnu.org; Tue, 23 Aug 2011 20:14:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qw170-00049G-Vd for emacs-orgmode@gnu.org; Tue, 23 Aug 2011 20:14:32 -0400 Received: from oproxy6-pub.bluehost.com ([67.222.54.6]:35221) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Qw170-00048G-PS for emacs-orgmode@gnu.org; Tue, 23 Aug 2011 20:14:30 -0400 In-Reply-To: <87fwkrpubg.fsf@gmail.com> (Eric Schulte's message of "Tue, 23 Aug 2011 17:44:03 -0600") 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: Eric Schulte Cc: =?utf-8?Q?Andr=C3=A1s?= Major , nicholas.dokos@hp.com, emacs-orgmode@gnu.org Eric Schulte writes: > 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) > > * top > ** not to be exported :noexp= ort: > #+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=3Dsomething :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 > | =3D=3D=3D=3D=3D=3D=3D=3D > |=20 > | Author: Eric Schulte > | Date: 2011-08-23 17:37:28 MDT > |=20 > |=20 > | Table of Contents > | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | 1 top=20 > | 1.1 to be exported=20 > |=20 > |=20 > | 1 top=20 > | ------ > |=20 > | 1.1 to be exported=20 > | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |=20 > |=20 > | 3 > |=20 > `---- > >> >> 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 w= ith >> 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 realit= y. >> --=20 Thomas S. Dye http://www.tsdye.com