Hi, I want to export to LaTeX and refer to tables and code blocks as in the example below. However a name with a colon, such as 'tab:my_data' used as a variable for a source block fails: org-babel-ref-resolve: Reference 'my_data' not found in this buffer Obviously, and perhaps not surprisingly, the use of the colon in the name seems to be problematic. Should this work? If not, is there a common alternative to the idiom tab:shootings_in_the_foot and fig:foot_with_hole? Cheers, Loris PS: In the example below, the last table is not exported to the LaTeX file, but this is presumably an unrelated issue ... Example: * Test with block names containing a colon ** Data My data can be found in Table [[tab:my_data]]. #+CAPTION: My data #+NAME: tab:my_data | a | b | |---+---| | 2 | 4 | | 3 | 9 | ** Code My code can be found in Listing [[code:my_code]]. #+CAPTION: My code #+NAME: code:my_code #+HEADER: :var data=tab:my_data :colnames yes #+BEGIN_SRC R d <- data #+END_SRC ** Results My results can be found in Table [[tab:my_results]]. #+CAPTION: My results #+NAME: tab:my_results #+RESULTS: code:my_code | a | b | |---+---| | 2 | 4 | | 3 | 9 | ** Conclusions Names with colons don't work. -- This signature is currently under construction.
On Thursday, 12 Feb 2015 at 16:19, Loris Bennett wrote: > Hi, > > I want to export to LaTeX and refer to tables and code blocks as in the > example below. However a name with a colon, such as 'tab:my_data' used > as a variable for a source block fails: > > org-babel-ref-resolve: Reference 'my_data' not found in this buffer The problem is that you need to get rid of the empty lines between the table information (name, caption) and the actual table: > My data can be found in Table [[tab:my_data]]. > > #+CAPTION: My data > #+NAME: tab:my_data > > | a | b | > |---+---| > | 2 | 4 | > | 3 | 9 | Delete the line after the #+name and it will work: if you look at the LaTeX, you'll see a table environment around the tabular structure and that's needed to get labels that you can referece. Not sure why the empty line matters, mind you... HTH, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-816-gae83b3
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --] Hi Eric, Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Thursday, 12 Feb 2015 at 16:19, Loris Bennett wrote: >> Hi, >> >> I want to export to LaTeX and refer to tables and code blocks as in the >> example below. However a name with a colon, such as 'tab:my_data' used >> as a variable for a source block fails: >> >> org-babel-ref-resolve: Reference 'my_data' not found in this buffer > > The problem is that you need to get rid of the empty lines between the > table information (name, caption) and the actual table: > >> My data can be found in Table [[tab:my_data]]. >> >> #+CAPTION: My data >> #+NAME: tab:my_data >> >> | a | b | >> |---+---| >> | 2 | 4 | >> | 3 | 9 | > > Delete the line after the #+name and it will work: if you look at the > LaTeX, you'll see a table environment around the tabular structure and > that's needed to get labels that you can referece. > > Not sure why the empty line matters, mind you... > > HTH, > eric In my ECM and in my original posting there are no empty lines between the table information and the actual table (see attached screenshot of my original ECM). However, I can see that in your quoted version above there is one. [-- Attachment #2: ecm.org --] [-- Type: image/png, Size: 80656 bytes --] [-- Attachment #3: Type: text/plain, Size: 287 bytes --] It seems as if at some point extraneous lines are being inserted into my original posting, although it looks all right to me. Or it's a case of the Inverse Emperor's New Newlines and I am too foolish to see them ... Cheers, Loris -- This signature is currently under construction.
On Friday, 13 Feb 2015 at 08:49, Loris Bennett wrote:
[...]
> In my ECM and in my original posting there are no empty lines between
> the table information and the actual table (see attached screenshot of
> my original ECM). However, I can see that in your quoted version above
> there is one.
Ummm, interesting. The way to avoid this issue may be to actually
attach a file instead of pasting the contents into the email. Can you
attach your ECM so that we can see what happens with it?
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-727-ga1cdc6.dirty
[-- Attachment #1: Type: text/plain, Size: 553 bytes --] Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Friday, 13 Feb 2015 at 08:49, Loris Bennett wrote: > > [...] > >> In my ECM and in my original posting there are no empty lines between >> the table information and the actual table (see attached screenshot of >> my original ECM). However, I can see that in your quoted version above >> there is one. > > Ummm, interesting. The way to avoid this issue may be to actually > attach a file instead of pasting the contents into the email. Can you > attach your ECM so that we can see what happens with it? [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: ecm --] [-- Type: text/x-org, Size: 581 bytes --] * Test with block names containing a colon ** Data My data can be found in Table [[tab:my_data]]. #+CAPTION: My data #+NAME: tab:my_data | a | b | |---+---| | 2 | 4 | | 3 | 9 | ** Code My code can be found in Listing [[code:my_code]]. #+CAPTION: My code #+NAME: code:my_code #+HEADER: :var data=tab:my_data :colnames yes #+BEGIN_SRC R d <- data #+END_SRC ** Results My results can be found in Table [[tab:my_results]]. #+CAPTION: My results #+NAME: tab:my_results #+RESULTS: code:my_code | a | b | |---+---| | 2 | 4 | | 3 | 9 | ** Conclusions Names with colons don't work. [-- Attachment #3: Type: text/plain, Size: 53 bytes --] -- This signature is currently under construction.
"Loris Bennett" <loris.bennett@fu-berlin.de> writes:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Friday, 13 Feb 2015 at 08:49, Loris Bennett wrote:
>>
>> [...]
>>
>>> In my ECM and in my original posting there are no empty lines between
>>> the table information and the actual table (see attached screenshot of
>>> my original ECM). However, I can see that in your quoted version above
>>> there is one.
>>
>> Ummm, interesting. The way to avoid this issue may be to actually
>> attach a file instead of pasting the contents into the email. Can you
>> attach your ECM so that we can see what happens with it?
>
> * Test with block names containing a colon
> ** Data
> My data can be found in Table [[tab:my_data]].
> #+CAPTION: My data
> #+NAME: tab:my_data
> | a | b |
> |---+---|
> | 2 | 4 |
> | 3 | 9 |
>
> ** Code
>
> My code can be found in Listing [[code:my_code]].
>
> #+CAPTION: My code
> #+NAME: code:my_code
> #+HEADER: :var data=tab:my_data :colnames yes
> #+BEGIN_SRC R
> d <- data
> #+END_SRC
>
> ** Results
>
> My results can be found in Table [[tab:my_results]].
>
> #+CAPTION: My results
> #+NAME: tab:my_results
> #+RESULTS: code:my_code
> | a | b |
> |---+---|
> | 2 | 4 |
> | 3 | 9 |
>
> ** Conclusions
>
> Names with colons don't work.
The above was attached with Gnus 'C-c RET f', MIME type 'text/x-org'.
Reading with Gnus, I don't see any blank lines between the table info
and the table itself.
Just to get back to the original question: Should and does
'tab:my_data' work as a value for a variable in a source block header?
I get
Reference 'my_data' not found in this buffer
If I replace the colon with '_', ';', or even '=', everything works as
expected.
Cheers,
Loris
--
This signature is currently under construction.
"Loris Bennett" <loris.bennett@fu-berlin.de> writes: > The above was attached with Gnus 'C-c RET f', MIME type 'text/x-org'. But you attached it as inline, so the same problems could arise. To be sure to transfer the file unmodified, choose "attachment" as disposition. > Reading with Gnus, I don't see any blank lines between the table > info and the table itself. It depends on your Gnus configuration. If you set (setq gnus-inhibit-mime-unbuttonizing t) then at least my version of Gnus (v5.13) does indeed split the buffer in multiple pieces with additional newlines. -- Until the next mail..., Stefan.
[-- Attachment #1: Type: text/plain, Size: 445 bytes --] Stefan Nobis <stefan-ml@snobis.de> writes: > "Loris Bennett" <loris.bennett@fu-berlin.de> writes: > >> The above was attached with Gnus 'C-c RET f', MIME type 'text/x-org'. > > But you attached it as inline, so the same problems could arise. To be > sure to transfer the file unmodified, choose "attachment" as > disposition. Thanks for that explanation. I don't do much attaching these days. Here is the file again as a proper attachment. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: ecm --] [-- Type: text/x-org, Size: 581 bytes --] * Test with block names containing a colon ** Data My data can be found in Table [[tab:my_data]]. #+CAPTION: My data #+NAME: tab:my_data | a | b | |---+---| | 2 | 4 | | 3 | 9 | ** Code My code can be found in Listing [[code:my_code]]. #+CAPTION: My code #+NAME: code:my_code #+HEADER: :var data=tab:my_data :colnames yes #+BEGIN_SRC R d <- data #+END_SRC ** Results My results can be found in Table [[tab:my_results]]. #+CAPTION: My results #+NAME: tab:my_results #+RESULTS: code:my_code | a | b | |---+---| | 2 | 4 | | 3 | 9 | ** Conclusions Names with colons don't work. [-- Attachment #3: Type: text/plain, Size: 709 bytes --] >> Reading with Gnus, I don't see any blank lines between the table >> info and the table itself. > > It depends on your Gnus configuration. If you set > > (setq gnus-inhibit-mime-unbuttonizing t) > > then at least my version of Gnus (v5.13) does indeed split the buffer > in multiple pieces with additional newlines. I haven't customised gnus-inhibit-mime-unbuttonizing and it has the value 'nil'. If I read the thread via http://permalink.gmane.org/gmane.emacs.orgmode/94919 there are also no extra newlines. Does anyone else apart from Eric also see space between table header and table? BTW, I'm still more interested in the colon thing ... -- This signature is currently under construction.
On Friday, 13 Feb 2015 at 13:36, Loris Bennett wrote:
> Stefan Nobis <stefan-ml@snobis.de> writes:
>
>> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>>
>>> The above was attached with Gnus 'C-c RET f', MIME type 'text/x-org'.
>>
>> But you attached it as inline, so the same problems could arise. To be
>> sure to transfer the file unmodified, choose "attachment" as
>> disposition.
>
> Thanks for that explanation. I don't do much attaching these days.
> Here is the file again as a proper attachment.
I can now confirm that there are indeed problems with : in both table
names and in the names of results.
I am using a relatively up to date version of org (day or so old).
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-820-gd92ef9
"Loris Bennett" <loris.bennett@fu-berlin.de> writes: > Hi, > > I want to export to LaTeX and refer to tables and code blocks as in the > example below. However a name with a colon, such as 'tab:my_data' used > as a variable for a source block fails: > > org-babel-ref-resolve: Reference 'my_data' not found in this buffer > Yes, it looks as if the babel header parsing code is a bit picky: changing just tab:my_data to tabmy_data everywhere it occurs is enough for the export to succeed. > Obviously, and perhaps not surprisingly, the use of the colon in the > name seems to be problematic. > > Should this work? If not, is there a common alternative to the idiom > tab:shootings_in_the_foot and fig:foot_with_hole? > > Cheers, > > Loris > > PS: In the example below, the last table is not exported to the LaTeX > file, but this is presumably an unrelated issue ... > Yes, you need ":exports both" for that. > Example: > > * Test with block names containing a colon > ** Data > My data can be found in Table [[tab:my_data]]. > #+CAPTION: My data > #+NAME: tab:my_data > | a | b | > |---+---| > | 2 | 4 | > | 3 | 9 | > > ** Code > > My code can be found in Listing [[code:my_code]]. > > #+CAPTION: My code > #+NAME: code:my_code > #+HEADER: :var data=tab:my_data :colnames yes > #+BEGIN_SRC R > d <- data > #+END_SRC > > ** Results > > My results can be found in Table [[tab:my_results]]. > > #+CAPTION: My results > #+NAME: tab:my_results > #+RESULTS: code:my_code > | a | b | > |---+---| > | 2 | 4 | > | 3 | 9 | > > ** Conclusions > > Names with colons don't work. Nick
Hello,
"Loris Bennett" <loris.bennett@fu-berlin.de> writes:
> BTW, I'm still more interested in the colon thing ...
Babel apparently supports (undocumented) "filename:reference" syntax for
foreign references. In your case, "tab:my_data" is mistakenly seen as
a reference to "my_data" in the file "tab".
As a safety measure, I suggest not using colons in reference names.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>> BTW, I'm still more interested in the colon thing ...
>
> Babel apparently supports (undocumented) "filename:reference" syntax for
> foreign references. In your case, "tab:my_data" is mistakenly seen as
> a reference to "my_data" in the file "tab".
>
> As a safety measure, I suggest not using colons in reference names.
>
>
> Regards,
Thanks for the information. I'll probably use "tab~my_date". As yet I
haven't noticed this trigger any other undocumented features ...
--
This signature is currently under construction.