[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 nicolasgoaziou.fr> writes: > > Hello, > > Roland DONAT 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] :RESULTS: drawer exported in LaTeX
Nick Dokos gmail.com> writes:
>
> Roland DONAT 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
[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] Babel : python generate org source block with an extra comma before * characters
Thorsten Jolitz gmail.com> writes: > > Roland DONAT 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.
Re: [O] Babel : python generate org source block with an extra comma before * characters
Thorsten Jolitz 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.
[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] How to pass named table reference in source block variable
Eric Schulte 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 <
Re: [O] How to pass named table reference in source block variable
Thomas S. Dye tsdye.com> writes: > > Roland Donat 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
Thomas S. Dye 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.
Re: [O] How to pass named table reference in source block variable
Thorsten Jolitz 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.
[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 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 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 MY-PATH/)]
Andreas Röhler 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 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.
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]
Andreas Röhler 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 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] org-babel, python, encoding and table
Nick Dokos gmail.com> writes: > > Andreas Röhler easy-emacs.de> writes: > > > Am 07.05.2013 20:18, schrieb Eric Schulte: > >> Andreas Röhler easy-emacs.de> writes: > >> ... > >> Maybe Python simply needs to be convinced to print in utf-8 format? > > > > Get the wrong results with a Ipython0.12, but correct with Python3.2.3 and Python3.3 - all called from Emacs24.3 > > unicode handling is one of the big changes between Python 2.x and Python > 3.x. It's good to know that Python 3.x seems to make it trivial to > handle unicode correctly (although there might still be dragons there). > > Here are some links: > > http://docs.python.org/2/howto/unicode.html > http://docs.python.org/3/howto/unicode.html > > that might shed some light. > Thank you very much for your answers!!! Well, I read that Python 3.x has improved the encoding handling but for now I have to keep using 2.7.x Python version. Using Python outside of org-mode is not a problem to manage encoding correctly. In general, you can use encode/decode methods to get what you want. Then, using the print function turns the coded character into human readable ones. But, what is hurting my poor little neurone is the fact that I don't understand why I get the correct result when the evaluation returns a single value and a wrong answer with a table. I think I have to understand how org-babel builds a table from a Python list of lists but I have to confess that I'm afraid of reading Lisp programs, though Emacs is my best friend ;)... Well, I'll keep on investigating on that subject Thanks again for your help! 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.
Re: [O] [orgmode 7.7] - Latex export problem with footnote, macro and code block evaluation
Hello,
Thank you for your answer.
Yes, I use orgmode 7.7-2, it seems to be the latest packaged version
available on linux.
I have just reproduced the bug on ubuntu this evening...
The problem only happens while latex exporting. For example, an ascii export
works fine.
Thanks again for your time.
Regards,
Roland.
2011/10/5 Nicolas Goaziou
> Hello,
>
> Roland writes:
>
> > Hello again,
> >
> > I just add some complements to the problem.
> >
> > First, here is a more compact buffer to reproduce the bug :
> >
> > == 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]
> >
> > #+MACRO: TBL src_emacs-lisp[:var v=$1[$2,$3]]{v}
> >
> > #+TBLNAME: test-macro
> > | 1 | 2 |
> > | 3 | 4 |
> >
> > * A footnote
> >
> > A footnote [fn:1: yihaa!]
> >
> > * A macro
> >
> > The value (1,1) of table test-macro is {{{TBL(test-macro,1,1)}}}.
> >
> > * A code block latex
> >
> > #+begin_src latex
> > $$a^{2} = b^{2} + c^{2}$$
> > #+end_src
> >
> > == cut here end ==
>
> I can't reproduce it on latest Org. If you're not using that version,
> you should upgrade: some bug fixing happened to footnotes since 7.7.
>
> Now, if it happens on that latest version, I will look at it again.
>
> Regards,
>
> --
> Nicolas Goaziou
>
[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}
<>
\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.
