emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Andreas Leha <andreas.leha@med.uni-goettingen.de>
To: emacs-orgmode@gnu.org
Subject: Re: Org Babel resolution of `:var` value reference inconsistent
Date: Mon, 02 Nov 2015 09:01:21 +0000	[thread overview]
Message-ID: <olua8qwixlq.fsf@med.uni-goettingen.de> (raw)
In-Reply-To: 8737woetng.fsf@toshiba.i-did-not-set--mail-host-address--so-tickle-me

Hi myq,

myq <myqlarson@gmail.com> writes:
> Sometime since Org version 8.3beta and now, the way Org Babel resolves
> the value of the `:var` header argument when assigned to a reference has
> changed.
>
> Previously, the following would work when exporting:
>
> * test
>
> #+BEGIN_SRC R :var dat=table-data
>   print(summary(dat));
> #+END_SRC
>
> ** COMMENT
>
> #+TBLNAME: table-data
> | number | measurement |
> |--------+-------------|
> | 1      | 10          |
>
>
> The above /still/ works when manually evaluating the block (C-c C-c whil
> in the block), but when exporting, the following error is thrown:
> `org-babel-ref-resolve: Reference `table-data' not found in this buffer`
>
> Curiously, the following tweak works for both manual evaluation and for
> exporting and produces the same results that the above file used to
> produce:
>
> #+OPTIONS: inline:nil
> * test
>
> #+BEGIN_SRC R :var dat=table-data
>   print(summary(dat));
> #+END_SRC
>
> *************** test
> #+TBLNAME: table-data
> | number | measurement |
> |--------+-------------|
> | 1      | 10          |
> *************** END
>
> This seems to be a bug, but perhaps there is a reason for this new
> behaviour?
>
> Thank you in advance for any insights.

There are two ways to exclude subtrees from export: the COMMENT keyword
and the :noexport: tag.  I think what you want to use here is the
:noexport: tag.

Here is the difference:

- COMMENTing a subtree is meant to be (roughly?) the same as putting '# '
  at the beginning of all the lines from that region.

- The :noexport: tag will simply skip the region from export.

So, to me it is more surprising that the manual execution works.  For
instance, I might have two tables with the same name.  Then, COMMENTing
one of them should ensure that the other one is used.

HTH,
Andreas

next prev parent reply	other threads:[~2015-11-02  9:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02  7:40 Org Babel resolution of `:var` value reference inconsistent myq
2015-11-02  9:01 ` Andreas Leha [this message]
2015-11-02 13:19   ` Nick Dokos
2015-11-04 12:14     ` Andreas Leha
2015-11-05 12:56       ` Martin Carlé
2015-11-05 14:48         ` Nicolas Goaziou
2015-11-05 20:53           ` Andreas Leha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=olua8qwixlq.fsf@med.uni-goettingen.de \
    --to=andreas.leha@med.uni-goettingen.de \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).