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:
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:
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
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
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
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
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
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)
|
|
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
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).
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
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
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
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|
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
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
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.
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
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
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
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
21 matches
Mail list logo
