[O] [bug suspected] Org tangles #+HEADER in the source code when using :comments org
Dear orgmode community, My problem is very simple. I have the following piece of org buffer : My piece of org buffer * Exemple : =hello_world= Some very explicit comments... #+HEADER: :tangle ./hello_world.py #+HEADER: :padline yes #+HEADER: :eval no #+HEADER: :comments org #+HEADER: :exports none #+BEGIN_SRC python a = Hello World! #+END_SRC end of org buffer When I tangle the file, I would have expected this : expected hello_world.py ## Exemple : hello_world ## Some very explicit comments a = Hello World end of expected hello_world.py But instead, I get : hello_world.py ## Exemple : hello_world ## Some very explicit comments ## #+HEADER: :tangle ./hello_world.py ## #+HEADER: :padline yes ## #+HEADER: :eval no ## #+HEADER: :comments org ## #+HEADER: :exports none a = Hello World end of hello_world.py I can imagine my question : Why org keeps the ## #+HEADER lines when tangling? Is it possible to remove it? Is it a bug? I use org-mode 8.2.5h on Linux. Thank you very much for your help! Cheers, Roland.
[O] Tangle source block with options :comments org
Dear orgmode community, My problem is very simple. I have the following piece of org buffer : My piece of org buffer * Exemple : =hello_world= Some very explicit comments... #+HEADER: :tangle ./hello_world.py #+HEADER: :padline yes #+HEADER: :eval no #+HEADER: :comments org #+HEADER: :exports none #+BEGIN_SRC python a = Hello World! #+END_SRC end of org buffer When I tangle the file, I would have expected this : expected hello_world.py ## Exemple : hello_world ## Some very explicit comments a = Hello World end of expected hello_world.py But instead, I get : hello_world.py ## Exemple : hello_world ## Some very explicit comments ## #+HEADER: :tangle ./hello_world.py ## #+HEADER: :padline yes ## #+HEADER: :eval no ## #+HEADER: :comments org ## #+HEADER: :exports none a = Hello World end of hello_world.py I can imagine my question : Why org keeps the ## #+HEADER lines when tangling? Is it possible to remove it? I use org-mode 8.2.5h on Linux. Thank you very much for your help! Cheers, Roland.
Re: [O] :RESULTS: drawer exported in LaTeX
Hello, Nicolas Goaziou mail at nicolasgoaziou.fr writes: Hello, Roland DONAT roland.donat at gmail.com writes: You're right, there is something wrong between the parser and the headlines... I hope it's a bug because I can't think of a reason to prevent user from inserting headlines between drawers, and I pointed, I haven't other non-dirty solution ;) Only headlines can contain headlines. This is the top-most syntax element in Org, you cannot put it into something smaller. Regards, Ok, I understand... That I'm dead :(. Thanks anyway for the explanation, Regards, Roland.
Re: [O] Babel : python generate org source block with an extra comma before * characters
Thorsten Jolitz tjolitz at gmail.com writes: Roland DONAT roland.donat at gmail.com writes: To do so, I tried to use de drawer option. It gives me the good result with a drawer but then when I export my org buffer to latex, the drawers :RESULTS: is also exported which is not cool... Did you try header args ':exports code ' or ':exports none'? Sorry for the late reply and thanks for your post. Yes I did and it does't work since these options do exactly what they are supposed to. So : - :exports code just exports my python source code. - :exports none exports nothing. But unfortunately I realised that the BEGIN_ORG drawer was also exported which is not what I want. So, I will create another post on that specific subject. Cheers.
[O] :RESULTS: drawer exported in LaTeX
Dear Orgmode community, I have this piece of python code that generate Orgmode text : #+NAME: test #+HEADER: :session test1 #+HEADER: :results value drawer #+BEGIN_SRC python a = ** H1\nblabla\n** H2\nbloblo a #+END_SRC #+RESULTS: test :RESULTS: ** H1 blabla ** H2 bloblo :END: But when I export my document in LaTeX, the :RESULTS: drawer appears in the final pdf which it's not cool... I have a d:nil in my OPTIONS header. My configuration : - Org 8.2.5h on Linux Mint 16. - Python 3 Any help would be much appreciated! Thanks. Roland.
Re: [O] :RESULTS: drawer exported in LaTeX
Nick Dokos ndokos at gmail.com writes: Roland DONAT roland.donat at gmail.com writes: Dear Orgmode community, I have this piece of python code that generate Orgmode text : #+NAME: test #+HEADER: :session test1 #+HEADER: :results value drawer #+BEGIN_SRC python a = ** H1\nblabla\n** H2\nbloblo a #+END_SRC #+RESULTS: test :RESULTS: ** H1 blabla ** H2 bloblo :END: But when I export my document in LaTeX, the :RESULTS: drawer appears in the final pdf which it's not cool... I have a d:nil in my OPTIONS header. There is either a bug in the parser or a drawer cannot contain headlines (probably the latter): running org-element-parse-buffer on the following: --8---cut here---start-8--- #+STARTUP: noindent #+OPTIONS: toc:nil * foo :RESULTS: ** foo1 blabla bloblo :END: * Local variables :noexport: # Local Variables: # org-export-with-drawers: (RESULTS) # End: --8---cut here---end---8--- gives me: --8---cut here---start-8--- (org-data nil (section (:begin 1 :end 41 :contents-begin 1 :contents-end 40 :post-blank 1 :parent #0) (keyword (:key \STARTUP\ :value \noindent\ :begin 1 :end 21 :post- blank 0 :post-affiliated 1 :parent #1)) (keyword (:key \OPTIONS\ :value \toc:nil\ :begin 21 :end 40 :post- blank 0 :post-affiliated 21 :parent #1))) (headline (:raw-value \foo\ :begin 41 :end 87 :pre-blank 0 :contents- begin 47 :contents-end 86 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil :archivedp nil :commentedp nil :title (#(\foo\ 0 3 (:parent #1))) :parent #0) (section (:begin 47 :end 58 :contents-begin 47 :contents-end 57 :post- blank 1 :parent #1) (paragraph (:begin 47 :end 57 :contents-begin 47 :contents-end 57 :post- blank 0 :post-affiliated 47 :parent #2) #(\:RESULTS:\\n\ 0 10 (:parent #3 (headline (:raw-value \foo1\ :begin 58 :end 86 :pre-blank 0 :contents- begin 66 :contents-end 86 :level 2 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :title (#(\foo1\ 0 4 (:parent #2))) :parent #1) (section (:begin 66 :end 87 :contents-begin 66 :contents-end 86 :post- blank 1 :parent #2) (paragraph (:begin 66 :end 80 :contents-begin 66 :contents-end 80 :post- blank 0 :post-affiliated 66 :parent #3) #(\blabla\\nbloblo\\n\ 0 14 (:parent #4))) (drawer (:begin 80 :end 86 :drawer-name \END\ :contents-begin nil :contents-end nil :post-blank 0 :post-affiliated 80 :parent #3) (headline (:raw-value \Local variables\ :begin 87 :end 198 :pre-blank 1 :contents-begin 133 :contents-end 198 :level 1 :priority nil :tags (\noexport\) :todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :title (#(\Local variables\ 0 15 (:parent #1))) :parent #0) (section (:begin 133 :end 198 :contents-begin 133 :contents-end 198 :post-blank 0 :parent #1) (comment (:begin 133 :end 198 :value \Local Variables:\\norg-export-with-drawers: (\\\RESULTS\\\)\\nEnd:\ :post-blank 0 :post-affiliated 133 :parent #2) --8---cut here---end---8--- so :RESULTS: is somehow misinterpreted as a paragraph and :END: as an empty drawer, instead of as the end of the RESULTS drawer. If there is no headline inside the drawer, then there is no misinterpretation, IOW the following works: --8---cut here---start-8--- #+STARTUP: noindent #+OPTIONS: toc:nil * foo :RESULTS: blabla bloblo :END: * Local variables :noexport: # Local Variables: # org-export-with-drawers: (RESULTS) # End: --8---cut here---end---8--- The final verdict has to be issued by Nicolas however. If it's not a bug, then you will have to modify your method (I would have said that raw is the best solution, but since you have already rejected that, I'm not sure what else to suggest). -- Nick Thank you very much for your analysis! You're right, there is something wrong between the parser
[O] Babel : python generate org source block with an extra comma before * characters
Dear Orgmode community, Thanks in advance to take some time to help me with my problem... Here is what is making me very sad : I have a python (python 3 interpreter) source block that I use to generate parts of a report written in Orgmode. Suppose we have this little example : #+NAME: test #+BEGIN_SRC python :results value org :session test report = *** header 1 My pretty report *** header 2 Ah ah! With that stuff, I will increase my *productivity*!!! report #+END_SRC What I get is : #+RESULTS: test #+BEGIN_SRC org ,*** header 1 My pretty report ,*** header 2 Ah ah, with that stuff, I will increase my *productivity*!!! #+END_SRC My question : Why Orgmode adds the comma before the star character??? In the manual, I read some things about comma-escaping in Org source block so my intuition tells me that my problem has something to do with that but I wasn't able to solve it for now. My configuration : - Org 8.2.5h on Linux Mint 16. - Python 3 Any help would be much appreciated! Thanks. Roland.
Re: [O] Babel : python generate org source block with an extra comma before * characters
Thorsten Jolitz tjolitz at gmail.com writes: This is because this function was applied to the results ,[ C-h f org-escape-code-in-region RET ] | org-escape-code-in-region is an interactive compiled Lisp function in | `org-src.el'. | | (org-escape-code-in-region BEG END) | | Escape lines between BEG and END. | Escaping happens when a line starts with *, #+, ,* or | ,#+ by appending a comma to it. | | [back] ` Not sure how to get rid of this, maybe via :results raw? I'm not aware of a configuration variable for this, but it surely exists. Thank you. It helps me much! Based on your answer, I copy-paste the code of the function org-escape- code-in-region in a source block in my org buffer and modify the code to prevent it from inserting the comma. It's a little bit dirty but it works. Using the raw option produces a correct result but I need the generated code to be decorated with a drawer to automatically replace the result at each code execution. To do so, I tried to use de drawer option. It gives me the good result with a drawer but then when I export my org buffer to latex, the drawers :RESULTS: is also exported which is not cool... Well, thanks again! Roland.
Re: [O] How to pass named table reference in source block variable
Thomas S. Dye tsd at tsdye.com writes: Roland Donat roland.donat at gmail.com writes: Perhaps this can help: http://orgmode.org/worg/org-contrib/babel/examples/lob-table- operations.html Alternatively, you might pass the table to a code block of a language that understands tables, such as an R data frame, and use that language to retrieve values by name. hth, Tom Thank you for the link, I'll check it but seems that it won't solve the problem. But anyway, I found a workaround that doesn't involve to insert table reference. What is the workaround? All the best, Tom Well, my main objective was to write piece of code in a given language X including information stored in some org-table. So my solution for now was to create some python functions able to generate my code. I use babel to pass my org-table as input to the python function and the result is another source block of language X containing the code taking into account the information of my org-table. I recognized that the solution seems quite heavy but I have already developped some python wrapper for my language X so It takes me only 2 hours to do the job. All the best. Roland.
Re: [O] How to pass named table reference in source block variable
Eric Schulte schulte.eric at gmail.com writes: It sounds like you want to use tables like key-value stores. I think adding such behavior directly to Org-mode would overly complicate the data structures passed between code blocks (which currently only consists of scalars and tables). However, maybe the following could work. Attachment (key-value.org): text/x-org, 776 bytes Cheers, Thanks for the attachment. It works fine indeed! But should it be so complicated to add this behavior to Org-mode? I can rewrite your table as follows : #+name: table | | keys | values | |---+--+| | | foo | 1 | | ^ | | foo| | | bar | 2 | | ^ | | bar| Now I can refer to bar value as $bar in org-table. So, my suggestion is only to mimic this feature to assign value of source block variable like : #+headers: :results verbatim #+begin_src sh :var foo=table$foo :var bar=table$bar cat EOF Pulling the data from the above table we find that foo is $foo and baz is $bar. EOF #+end_src But anyway, thanks for the solution. Cheers. Roland.
Re: [O] How to pass named table reference in source block variable
Thorsten Jolitz tjolitz at gmail.com writes: This does the job in Emacs Lisp: #+TBLNAME: T | | x | 1 | | ^ | | varx | #+begin_src emacs-lisp :var x=T[0,-1] x #+end_src #+results: : 1 Thanks for the answer but in fact, my objective is precisely to avoid using the indices of the value I want to pass as input of the code block. My goal is to use the cell name reference varx which would make the code block simpler to maintain. Indeed, if I add new data on the top of table T, I wouldn't have to change the reference in the code block since the name reference is fixed.
Re: [O] How to pass named table reference in source block variable
Thomas S. Dye tsd at tsdye.com writes: Perhaps this can help: http://orgmode.org/worg/org-contrib/babel/examples/lob-table- operations.html Alternatively, you might pass the table to a code block of a language that understands tables, such as an R data frame, and use that language to retrieve values by name. hth, Tom Thank you for the link, I'll check it but seems that it won't solve the problem. But anyway, I found a workaround that doesn't involve to insert table reference. It's a pity that I am so bad at Lisp because I feel this feature wouldn't be too complicated to code, especially if the reference mechanism is already implemented. Thank you again! Cheers, Roland.
[O] How to pass named table reference in source block variable
Hello, I have the following table : #+TBLNAME: T | | x | 1 | | ^ | | varx | And I would like to use the reference T$var_x (=1) as input in a source block variable. For example, I would have expected the following behavior for this source code : #+begin_src python :var x=T$varx :return x x #+end_src #+RESULTS: : 1 But instead, I get the emacs message : org-babel-ref-resolve: Reference 'T$varx' not found in this buffer Any idea to produce the desired result would be much appreciated! Thanks you in advance. Roland.
Re: [O] org-babel, python, encoding and table
Andreas Röhler andreas.roehler at easy-emacs.de writes:
Am 07.05.2013 18:41, schrieb Eric Schulte:
#+NAME: test2
#+begin_src python :results value :preamble # -*- coding: utf-8 -*-
:return
a
a = ( ( é, a ), ( a, à ) )
b = é
#+end_src
#+RESULTS: test2
| \303\251 | a|
| a| \303\240 |
Maybe this isn't an execution problem, but is rather a buffer encoding
problem. I executed your example above in a small buffer (attached). I
then saved this buffer and was forced to specify an encoding, I selected
utf8. If I cat the resulting file from disk, the accented characters
appear correctly.
Confirming this.
BTW also return a[0][0] displays correct so far.
Cheers,
Andreas
Hello,
Just an update about this post.
I've kept on digging on the problem of org-babel python results that
produces encoding problems in
the emacs buffer when the requested results is turned into a org table.
To remind and illustrate the problem, here is an example :
#+name: pytab-test
#+begin_src python :results value :session :preamble # -*- coding: utf-8 -*-
:return a
a = ( ( é, a ), ( a, à ) )
a
#+end_src
#+TBLNAME: pytab-test
| \303\251 | a|
| a| \303\240 |
I have then two problems :
1. The characters are not well displayed in the buffer
2. If I try to save the buffer, emacs doesn't recognize the encoding and
tells me that utf-8-unix cannot encode these: \303 \251 [...]
So I decided to inspect what happened during the Python session...
Basically, Org-babel just write the str conversion of my tuple ( ( é, a
), ( a, à ) ) (that appears (('\xc3\xa9',
'a'), ('a', '\xc3\xa0')) in the python interpreter) in a temporary file.
Then looking in this temporary file, I see that the strange characters are
written directly \xc3, \xa9, etc.
Consequently, my guess is that org-babel has maybe some difficulties to deal
with these characters
while reading the temporary file before displaying the results in the
buffer.
Unfortunately, this is just a guess and even less a solution... But am I on
relevant lead???
Thanks in advance for any help...
Roland.
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Andreas Röhler andreas.roehler at easy-emacs.de writes:
Am 08.05.2013 22:50, schrieb Roland Donat:
Yes, you're right Andreas. It fails to show the accented characters
if
you
try to print the entire tuple.
It fails too if you evaluate a[0][0] in your interpreter. You should
see
:
a[0][0]
'\xc3\xa9'
But print a[0][0] gives the expected answer 'é'
So, based on your successful experience consisting in returning a[0]
[0]
in
the orgmode source block, we can assume that org-babel use the python
print
function to display results in org buffer, aren't we?
Another strange behaviour, when you evaluate the src_block test given
in
example, you get :
| \303\251 | a|
| a| \303\240 |
Whereas I was expecting to get the same code than in the python
interpreter,
that is :
| \xc3\xa9 | a |
| a| '\xc3\xa0' |
In addition, when I try to save my buffer, Emacs doesn't recognize the
encoding of characters \303\251 and \303\240 and asks me to choose an
encoding. Then, I enter utf-8 and nothing happens BUT when I quit and
reopen
my file : the characters are printed correctly Too strange for
me
Cheers,
Roland.
so what about that:
a = ( ( é, a ), ( a, à ) )
for i, j in a:
print i, j
BTW previous post was sent prematurely..
Andreas
Yep, using a couple of for loops will work but the result won't return
as a
table which is a requirement for me.
To precise the context a littre more, I have basically 2 source blocks :
1) the famous python block which must return a table
2) a R block used to post-process the previous table
Well, thanks for your help.
I think I spent too much time on this so I'm thinking about changing my
approach. For example, put the result of the first step into a file and
then
process the file in step 2.
Best regards,
Roland.
Just playing a little bit with your example, what about this:
#+begin_src python :results output :preamble # -*- coding: utf-8 -*-
a = ( ( é, a ), ( a, à ) )
for i, j in a:
print(|%s | %s| % (i, j))
#+end_src
Yes Andreas! It works just fine for the python block. But when the python
result arrives as input of my R post
processing code, R receives the following string | é | a |\n| a | à |\n
whereas a data.frame is
expected. Indeed, theoretically, when a org-table is used as input of a R
source block, the
org-table is automatically converted into a data.frame which is very
convenient to handle data.
Here is my buffer :
#+name: pytab
#+begin_src python :results output raw :preamble # -*- coding: utf-8 -*-
a = ( ( é, a ), ( a, à ) )
for i, j in a:
print | {0} | {1} |.format( i, j )
#+end_src
#+TBLNAME: pytab
| é | a |
| a | à |
#+name: Rpostproc
#+begin_src R :results output :session :preamble # -*- coding: utf-8 -*-
:var tab=pytab
print( tab )
#+end_src
#+RESULTS: Rpostproc
: [1] | é | a |\n| a | à |\n
In fact, converting the results of my python block into a string looking
like an org-table is what I
used to do before I had to use a R block to post process results.
I assume that org-babel asks for a re-evaluation of pytab source block
when pytab is used as argument of another source block.
The problem stems from the fact that it's the direct evaluation of pytab
(a string) which is used and
not the org-table converted result as shown in the buffer.
Well, I could just convert the R string into a data.frame but it's very
complete with my real data
(non trivial separator problems).
A solution to this problem could be to force org-babel to take as argument
of the R code what is
really shown in the buffer and not the direct result of the python block.
Another solution could be
to stop the re-evaluation of the R arguments.
Anyway, thanks to spend time on this Andreas!
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
The bug so far affected the display only, not the data. Feeding R with the result returned from your original form should work. Best, Andreas Ah you're right It's a bit annoying to enter the encoding when Emacs asks for it but it works on the previous example. It's not the case with my real data but it's another problem to solve now ;). Thanks a lot for your help Best regards Roland.
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
hmm, indeed, shows up nicely now. Please close, cheers, Andreas That's right, it works with python3 but that is not the case with python2... Cheers, Roland.
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Andreas Röhler andreas.roehler at easy-emacs.de writes: Am 08.05.2013 15:20, schrieb Roland Donat: hmm, indeed, shows up nicely now. Please close, cheers, Andreas That's right, it works with python3 but that is not the case with python2... Cheers, Roland. python2 fails here already with a common shell, independently from Emacs. OTOH that works with python2: #+NAME: test #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a[0][0] a = ( ( é, a ), ( a, à ) ) #+end_src #+RESULTS: test : é Maybe there is a work-around from a[0][0] ? Yes, you're right Andreas. It fails to show the accented characters if you try to print the entire tuple. It fails too if you evaluate a[0][0] in your interpreter. You should see : a[0][0] '\xc3\xa9' But print a[0][0] gives the expected answer 'é' So, based on your successful experience consisting in returning a[0][0] in the orgmode source block, we can assume that org-babel use the python print function to display results in org buffer, aren't we? Another strange behaviour, when you evaluate the src_block test given in example, you get : | \303\251 | a| | a| \303\240 | Whereas I was expecting to get the same code than in the python interpreter, that is : | \xc3\xa9 | a | | a| '\xc3\xa0' | In addition, when I try to save my buffer, Emacs doesn't recognize the encoding of characters \303\251 and \303\240 and asks me to choose an encoding. Then, I enter utf-8 and nothing happens BUT when I quit and reopen my file : the characters are printed correctly Too strange for me Cheers, Roland.
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Yes, you're right Andreas. It fails to show the accented characters if you try to print the entire tuple. It fails too if you evaluate a[0][0] in your interpreter. You should see : a[0][0] '\xc3\xa9' But print a[0][0] gives the expected answer 'é' So, based on your successful experience consisting in returning a[0][0] in the orgmode source block, we can assume that org-babel use the python print function to display results in org buffer, aren't we? Another strange behaviour, when you evaluate the src_block test given in example, you get : | \303\251 | a| | a| \303\240 | Whereas I was expecting to get the same code than in the python interpreter, that is : | \xc3\xa9 | a | | a| '\xc3\xa0' | In addition, when I try to save my buffer, Emacs doesn't recognize the encoding of characters \303\251 and \303\240 and asks me to choose an encoding. Then, I enter utf-8 and nothing happens BUT when I quit and reopen my file : the characters are printed correctly Too strange for me Cheers, Roland. so what about that: a = ( ( é, a ), ( a, à ) ) for i, j in a: print i, j BTW previous post was sent prematurely.. Andreas Yep, using a couple of for loops will work but the result won't return as a table which is a requirement for me. To precise the context a littre more, I have basically 2 source blocks : 1) the famous python block which must return a table 2) a R block used to post-process the previous table Well, thanks for your help. I think I spent too much time on this so I'm thinking about changing my approach. For example, put the result of the first step into a file and then process the file in step 2. Best regards, Roland.
[O] org-babel, python, encoding and table
Hello, My problem is about python code evaluation with org-babel that should give a table containing accented characters. Here is an example : #+NAME: test1 #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return b a = ( ( é, a ), ( a, à ) ) b = é #+end_src #+RESULTS: test1 : é It's ok, no problem! But : #+NAME: test2 #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a a = ( ( é, a ), ( a, à ) ) b = é #+end_src #+RESULTS: test2 | \303\251 | a| | a| \303\240 | I don't understand why the accented characters are replaced by some codes when the results is interpreted as org-table... Any idea, workaround to solve my problem would be much appreciated! I use Org-mode version 8.0.2 (8.0.2-2-g93da18-elpaplus @ /home/roland/.emacs.d/elpa/org-plus-contrib-20130429/). Thanks in advance. Best regards, Roland.
[O] [orgmode 7.7] - Latex export problem with footnote, macro and code block evaluation
Hello everyone,
I am experience a very strange problem so that any help would be
appreciated!
I precise that I use org-mode 7.7 on Linux/Debian.
I tried to perform latex export of the following org file :
=== cut here begin ===
# -*- coding: utf-8 -*-
#+TITLE: Title
#+AUTHOR: Roland
#+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:{} f:t TeX:t author:t
#+LaTeX_CLASS: article
#+LaTeX_CLASS_OPTIONS: [a4paper,twoside,10pt]
#+LATEX_HEADER: \usepackage{booktabs}
#+MACRO: TBL src_emacs-lisp[:var v=$1[$2,$3]]{v}
#+TBLNAME: test-macro
| 1 |
#+TBLNAME: Test-latex
| A | B |
|---+---|
| 1 | 3 |
| 2 | 4 |
* The footnote
A footnote [fn:a: youhou!]
* The macro
The value (0,0) of table test-macro is {{{TBL(test-macro,0,0)}}}.
* The code block
#+begin_src latex :noweb yes
\begin{table}
\centering
\begin{tabularx}{0.9\textwidth}{p{1.5cm}X}
booktabs-2(table=test-latex)
\end{tabularx}
\end{table}
#+end_src
#+srcname: booktabs-2
#+begin_src emacs-lisp :var table='((:head) hline (:body))
(flet ((to-tab (tab)
(orgtbl-to-generic
(mapcar (lambda (lis)
(if (listp lis)
(mapcar (lambda (el)
(if (stringp el)
el
(format %S el))) lis)
lis)) tab)
(list :lend :sep:hline \\hline
(org-fill-template
\\toprule
%table
\\bottomrule\n
(list
(cons table
;; only use \midrule if it looks like there are column headers
(if (equal 'hline (second table))
(concat (to-tab (list (first table)))
\n\\midrule\n
(to-tab (cddr table)))
(to-tab table))
#+end_src
=== cut here end ===
Unfortunately, I get the error message : org-export-latex-preprocess: Wrong
type argument: integer-or-marker-p, nil
But when I comment the content of one of the 3 headers, the export is done
just fine. The combination of a footnote, a macro call and a code block
evaluation seems to be not compatible. Sounds weird, doesn't it?
Anybody see what is happening?
Thank you in advance for your help!
Roland.
