Re: [O] org-babel, python, encoding and table
Am 07.05.2013 22:05, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de writes: So it's up to choose the Python default interpreter. Unfortunatly (org-babel-do-load-languages 'org-babel-load-languages '((python3 . t))) seems not working. The language is still python (more or less). What you need to do is customize org-babel-python-command. Thanks. This reveals a bug in ob-python then. Will open a separate thread. Andreas
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
org-babel-python-mode was python3
Re: [O] Extending ODT export
Hi all, Takaaki ISHIKAWA tak...@ieee.org writes: Dear Julian, Sorry, the code is an old setting for the previous org. Please try org-odt-preferred-output-format. #+BEGIN_SRC emacs-lisp (setq org-odt-preferred-output-format pdf) (setq org-odt-convert-processes '((LibreOffice /Applications/LibreOffice.app/Contents/MacOS/soffice --headless --convert-to %f%x --outdir %d %i) (unoconv unoconv -f %f -o %d %i))) #+END_SRC Best, Takaaki On May 8, 2013, at 12:06 AM, Takaaki ISHIKAWA tak...@ieee.org wrote: Dear Julian, When I use soffice with exec-path setting, the ODT export is failed like you. So currently, I use the following setting: #+BEGIN_SRC emacs-lisp (setq org-export-odt-preferred-output-format pdf) (setq org-export-odt-convert-processes '((LibreOffice /Applications/LibreOffice.app/Contents/MacOS/soffice --headless --convert-to %f%x --outdir %d %i) (unoconv unoconv -f %f -o %d %i))) #+END_SRC It works fine for me. Best regards, Takaaki Ishikawa On May 7, 2013, at 10:51 PM, Julian M. Burgos jul...@hafro.is wrote: Hi Christian, The value for org-odt-convert-processes is ((LibreOffice soffice --headless --convert-to %f%x --outdir %d %i) (unoconv unoconv -f %f -o %d %i)) soffice is in my path, so I can run it from any directory. Carsten, I have permission in /home. That is where I had my trial org file. I have the same problem if I put my org file in other directory. Julian Carsten Dominik writes: On 7 mei 2013, at 14:29, Christian Moe m...@christianmoe.com wrote: Hi, Possible checks: What value do you have for org-odt-convert-processes? Does the command it provide launch LibreOffice services on your system? On my Mac, the default soffice command is not recognized out of the box; providing the full path to soffice (/Applications/LibreOffice.app/Contents/MacOS/soffice) helps. Also, it only seems to work when LibreOffice isn't already running, though I may be wrong about that (I just tried this for the first time). Another check: Do you have write permissions in /home ? Why is it trying to write the file to that location? - Carsten Yours, Christian Julian M. Burgos writes: By the way, it also fails with the pdf and doc options... Julian M. Burgos writes: Hello everyone, I want to export via ODT directly into a docx format. Following the instructions in the manual, I added (setq org-odt-preferred-output-format docx) to my .emacs file. But if I try to do an export I get the following error message: Export to /home/trial.docx failed I am using org-mode 8.0.2, LibreOffice 3.5.7.2, and Fedora 17. Any ideas? Julian -- Julian Mariano Burgos, PhD Hafrannsóknastofnunin/Marine Research Institute Skúlagata 4, 121 Reykjavík, Iceland Sími/Telephone : +354-5752037 Bréfsími/Telefax: +354-5752001 Netfang/Email: jul...@hafro.is -- Takaaki ISHIKAWA tak...@ieee.org GITI, Waseda University :) http://about.me/takaxp -- Takaaki ISHIKAWA tak...@ieee.org GITI, Waseda University :) http://about.me/takaxp I did not follow closely, but I remember that I had problems to use LibreOffice to convert a *already open* document. So, if you are viewing the doc in LibreOffice while you try your export, you might run into problems. This is a reported bug in LibreOffice. The suggested work-around is to use a temporary profile as in: libreoffice -env:UserInstallation=file:///tmp/LibO_Conversion --headless --invisible --convert-to txt:text $FILENAME /dev/null ^^^ You might try to add that to the conversion command and see whether it helps. Best, Andreas
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
Am 08.05.2013 09:12, schrieb Andreas Röhler: org-babel-python-mode was python3 e, org-babel-python-command
Re: [O] Exporting visible items not behaving as expected
Hello, Cameron Desautels cam...@gmail.com writes: I'm having a bit of trouble with exports. My understanding is that I should be able to create a sparse tree from a tag (C-c / m tag-name RET) and then export only the visible items (C-c C-e C-v t A) to get an export of just the items with that tag. What I'm getting instead is an export that only contains the top-level headers and I'm uncertain why this is happening. Any advice would be greatly appreciated. Details follow: The visible-only code was over simplistic. I fixed it in maint, so your example should export fine now. Thank you for reporting this. Regards, -- Nicolas Goaziou
Re: [O] org-babel, python, encoding and table
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
Re: [O] Problem with Google Calendar Synchronization
Guido Van Hoecke gui...@gmail.com writes: Hi, Thank you guys for your help. Got gawk from macports. Glad you got it. I did make use of whatever GNU awk provided and did not try to keep to vanilla awk. Sorry about that! Hitting data error now: gawk: ./importGoogleCalendar.awk:143: (FILENAME=- FNR=34026) fatal: strftime: second argument less than 0 or too big for time_t I am investigating this now and will report my findings Keep us posted. I've not seen this error before but I am not confident that the parsing of date and time stamps in the awk script is comprehensive. If you don't track it down, I would be happy to look at your calendar file. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-68-g40635b
[O] Org LaTeX export not setting default title?
All,
I just upgraded to 8.02, so I am trying out the new exporter. Nice.
A little nit. When I export a minimal org file, it should use the
name of the file or buffer as the title if I set nothing in #+TITLE:,
but it seems not to.
Here it a minimal Org file named 'Junk.org':
==
* First Headline
* Second Headline
==
And this is the LaTex, when I do an export LaTeX to buffer:
==
% Created 2013-05-08 Wed 05:03
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{amstext}
\usepackage{hyperref}
\tolerance=1000
\author{Daniel E. Doherty}
\date{\today}
\title{}
\hypersetup{
...
Note that the \title is empty, but should be \title{Junk}.
I do have some customizations set, but nothing that I can see would
affect the title.
Anyone else seeing this?
Regards,
Dan
Re: [O] another example
rasmus == rasmus Rasmus writes:
Uwe Brauer o...@mat.ucm.es writes:
Look the following examples
\begin{displaymath}
Xs,δ:=Hs,δ× Hs,δ+1× Hs,δ+1×
Hs+1,δ+2
\end{displaymath}
org-preview-latex-fragment does not work, change displaymath for
equation, again org-preview-latex-fragment does not work, but
\[ \]
does work, this is odd
1. The example you posted contains utf8 symbols and you'd likely need
unicodemath (the package) to display it. For this you'd need
xelatex or lualatex. But probably you wrote it as plain LaTeX code
in your document.
Hm it seems that the coding was changed when sending the formula, since
I wrote \delta in the original mail not δ.
In any case: *why* does \[ \] work, if it is question of a missing package?
2. displaymath is from amsmath. This works on my system:
#+BEGIN_SRC org
#+LATEX_HEADER: \usepackage{amsmath}
\begin{displaymath}
x=1
\end{displaymath}
#+END_SRC
Really?
Here is a minimal example
of a LaTeX file, which is not using amsmath, but the file is compiled as
it should be:
\documentclass{article}
\begin{document}
\begin{displaymath}
\int dx
\end{displaymath}
\end{document}
I also extended the corresponding configuration in org.el
(defcustom org-format-latex-header \\documentclass[12pt]{article}
\\usepackage[usenames]{color}
\\usepackage{amsmath}
\\usepackage{plain}
\\usepackage[mathscr]{eucal}
Uwe
smime.p7s
Description: S/MIME cryptographic signature
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 08.05.2013 09:12, schrieb Andreas Röhler: org-babel-python-mode was python3 e, org-babel-python-command I can't reproduce this problem. After evaluating the following (setq org-babel-python-command python3) The utf-8 example works perfectly for me (and apparently for the other poster in the previous thread as well). Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] using gnuplot's splot and every commands on org-mode table data
Paul Stansell paulstans...@gmail.com writes: Hi Eric, If I change your example org file a little by adding row and column names to the table as in the attached file I get the following behaviour that I don't understand: if I execute C-c on the shell function the file /tmp/data.gnuplot has the format that gnuplot can plot; however, if I execute C-c on the gnuplot function the form of /tmp/data.gnuplot is mangled with and () so it can no longer be plotted by the gnuplot command. Can you shed any light on this? Very weird, This does look like a bug to me. Can you isolate where the value of data in your example is first assigned the wrong value? Thanks for reporting. I will save your example for when I next have development time. Best, Thanks, Paul -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] using gnuplot's splot and every commands on org-mode table data
Paul Stansell paulstans...@gmail.com writes: Hi Eric, My view is that the removal of ''s will always be preferable for gnuplot as it uses what it calls datablocks which are delimited by blank lines (see, for example, http://gnuplot.sourceforge.net/docs_4.2/node121.html and http://gnuplot.sourceforge.net/docs_4.2/node61.html). Paul Hi Paul, I think examples like the following may be more common than data blocks. #+name: data | 1 | 2 | | 2 | 4 | | 3 | 8 | | | 16 | | || | 6 | 16 | | 7 | 8 | | | 4 | | 9 | 2 | #+begin_src gnuplot :var data=data :results silent plot data u 0:1, '' u 0:2 #+end_src Replacing s with blank space in the following breaks the resulting plot. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Org LaTeX export not setting default title?
Hi Dan, On Wed, May 8, 2013 at 6:06 AM, Daniel E. Doherty ded-...@ddoherty.net wrote: All, I just upgraded to 8.02, so I am trying out the new exporter. Nice. A little nit. When I export a minimal org file, it should use the name of the file or buffer as the title if I set nothing in #+TITLE:, but it seems not to. [snip] I am writing to say that I observe the same behavior that you do so it isn't something unique to your setup. I will let others say what Org's new exporter should do in this case, but let me point out that if you insert the default export template with C-c C-e # d TAB RET Then the file name (with extension removed) is inserted in the #+TITLE field and exported to the LaTeX buffer. I understand, though, that this probably isn't what you meant by minimal org file. Cheers, -- Jay
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
Am 08.05.2013 14:40, schrieb Eric Schulte: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 08.05.2013 09:12, schrieb Andreas Röhler: org-babel-python-mode was python3 e, org-babel-python-command I can't reproduce this problem. After evaluating the following (setq org-babel-python-command python3) The utf-8 example works perfectly for me (and apparently for the other poster in the previous thread as well). Cheers, hmm, indeed, shows up nicely now. Please close, cheers, Andreas
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/)]
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] ?
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] Org LaTeX export not setting default title?
Hello, Daniel E. Doherty ded-...@ddoherty.net writes: A little nit. When I export a minimal org file, it should use the name of the file or buffer as the title if I set nothing in #+TITLE:, but it seems not to. It should be fixed in maint. Thank you for reporting this. Regards, -- Nicolas Goaziou
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Am 08.05.2013 16:02, schrieb Roland Donat: 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 Seems utf-8 understands \303\251, which seems the same number as \xc3\xa9, i.e. the numeric character returned is ok. Failings
Re: [O] using gnuplot's splot and every commands on org-mode table data
Hi Eric, It seems to be the first hline that causes the problem. For example, if the table data in splot.org is replaced by #+name: data || x | |+---| | r1 | 1 | it gets exported correctly as x r1 1 by both the shell and gnuplot commands. However, if the data is replace by #+name: data |+---| || x | | r1 | 1 | it still gets exported correctly by the shell command but the gnuplot command exports it as hline ( x) (r1 1) Thanks for your help with this, Paul Very weird, This does look like a bug to me. Can you isolate where the value of data in your example is first assigned the wrong value? Thanks for reporting. I will save your example for when I next have development time. Best,
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Am 08.05.2013 16:02, schrieb Roland Donat: 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. so what about that: a = ( ( é, a ), ( a, à ) ) for i, j in a: print i, j BTW previous post was sent prematurely.. Andreas
Re: [O] using gnuplot's splot and every commands on org-mode table data
Hi Eric, In your last example are you illustrating the case of a data file with missing data? Replacing s with blank space in your example doesn't really break the plot, it's just that gnuplot interprets the first column of data as 1 2 3 16 6 7 4 9 and the second as 2 4 8 16 8 4 2 Gnuplot has a specific setting for handling missing values. It's common in gnuplot to use '?' to signify a missing value (type help missing at the gnuplot prompt). If, in your last example, you replace the missing values with '?' (without the quotes) and then type in gnuplot set datafile missing ? and then plot the data with plot data.txt u 0:1, '' u 0:2 you'll see that gnuplot handles it properly. Putting '?' in the blanks cells of the org mode table in your last attachment and plotting from within org mode gives a temporary data file containing '?', which gnuplot also handles correctly as it must recognise ? (with the quotes) as being a missing value. But org mode's behaviour of inserting in blank cells (instead of actual blanks) does break the use of every in gnuplot which is required by splot when plotting surfaces from data files (unless the data files are in matrix format). Also, inserting breaks the use of gnuplot's index which expects two blank lines to separate data sets in a single file, but I've never used this facility. I noticed that org mode writes table values of 'nan' and 'NaN' without the double quotes, but, for example, 'MaM' is written with double quotes, (as ''MaM') in the temporary data file. Also, I think it's generally better to remove the double quotes from around all strings exported by org mode for plotting by gnuplot as they're generally not needed (exceptions are strings which contain spaces which can be quoted so they are treated as a single entity by gnuplot). For example, there is a gnuplot demonstration script called datastrings.dem which plots data from a file called ctg-y2.dat. This data file has unquoted month names in the first column that are plotted as labels on the x-axis. Paul
Re: [O] Problem with Google Calendar Synchronization
Eric S Fraga e.fr...@ucl.ac.uk writes: Guido Van Hoecke gui...@gmail.com writes: Hi, Thank you guys for your help. Got gawk from macports. Glad you got it. I did make use of whatever GNU awk provided and did not try to keep to vanilla awk. Sorry about that! No prob at all! Hitting data error now: gawk: ./importGoogleCalendar.awk:143: (FILENAME=- FNR=34026) fatal: strftime: second argument less than 0 or too big for time_t I am investigating this now and will report my findings Keep us posted. I've not seen this error before but I am not confident that the parsing of date and time stamps in the awk script is comprehensive. If you don't track it down, I would be happy to look at your calendar file. There's no error in the script :) My ics file had a.o. my elder sister's birthday, and unfortunately her's as well as mine is (way) before the start of the epoch, so mktime returns a negative timestamp at line 63 and strftime at line 143 doesn't grok it. Anyway, I don't need these records as I have them in a separate anniversaries.org file that uses diary-style sexp entries for the birthdays. So Eric, rest assured, the script works fine for events occurring since the start of the epoch. It was quite a help to me. Thanks for your effort and for sharing it, Guido -- APL is a write-only language. I can write programs in APL, but I can't read any of them. -- Roy Keir
Re: [O] disable tangling for an entire section?
On Tue May 07 2013 at 07:23, Sebastien Vauban sva-n...@mygooglest.com wrote: Christian Moe wrote: Bill White writes: Is there a simple way to disable tangling for an entire section's code blocks? Or to put it a different way, can tangling be toggled at the section level and not just the code-block level? I tried this: ** a section in my file :PROPERTIES: :tangle: no :END: by analogy from #+PROPERTY: tangle yes in (info (org) Header arguments in Org mode properties), but code blocks in that section were still tangled. That should work, I think, and it does work for me (on 8.0.1). I cannot reproduce the problem. That must work, yes. Except if you have :tangle header arguments set on sub-subtrees, or on code blocks, of course. Thank you Christian and Sebastien for your replies. I was hoping that a higher-level setting would override all tangle settings under it, no matter what they might be. This would make it possible to change an entire section's tangling without fussing with each code block's setting. For example, I had hoped that the following would disable tangling for both code blocks, but for me[1] even under 'emacs -Q' the first block is tangled: * headline :PROPERTIES: :tangle: no :END: #+begin_src perl :tangle yes 2 + 2 #+end_src #+begin_src perl :tangle no 3 + 3 #+end_src [1]: Org-mode version 8.0.2 (release_8.0.2-61-g22dfa7 @ /home/billw/Dropbox/org/org-mode/lisp/) GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2013-03-11 on wri Cheers - bw -- Bill White . bi...@wolfram.com No ma'am, we're musicians.
[O] Change title and export filename based on code value?
I'd like to change the title of my report, and the exported pdf filename, based on a value I can change in the org-mode source. I have a source block like this: #+NAME: reporttype #+BEGIN_SRC elisp :results value silent :exports results Foo #+END_SRC I figured out how to do the title: #+TITLE My Report: call_reporttype()[:results raw] Results which is pretty neat (but wasn't easy to figure out, I'll work on that in the doc). ...but I'd also like to set the exported PDF filename based on the reporttype, but I'm not sure there is an option for that. Is there? And if there is, is there a way to interpolate my reporttype into it? -- Gary
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] Possible bug report - error with time string recognition in clocktable
The following clocktable line: #+BEGIN: clocktable :tstart -7d :tend now #+END: errors out on the tstart tend times According to all the documentation I can find, these are both valid 'special' time strings. Attempts to evaluate the clocktable with C-c C-c give the error: Updating dynamic block `clocktable' at line 57... org-parse-time-string: Not a standard Org-mode time string: -7d however this: #+BEGIN: clocktable :tstart 2013-05-08 Wed :tend 2013-05-09 Thu #+END: works just fine -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] INCLUDE directives in new org-mode
#+INCLUDE: date.org
I changed this to #+INCLUDE: date.org
* this is a test
--- date.org
{{{date(%d %b %Y)}}}
You want:
{{{time(%d %b %Y)}}}
I made this change as well, however the same results. Any thing in the
included file is copied verbatim...
-Tim
Re: [O] INCLUDE directives in new org-mode
At Tue, 07 May 2013 16:14:19 +0200,
Nicolas Goaziou wrote:
Hello,
Wiskey 5 Alpha wiskey5al...@gmail.com writes:
I am trying to use the #+INCLUDE directives to have template information
for a series of orgmode files that I want to export. Prior to upgrading to
v8, the below minimal example was working. But as of the upgrade, any
text in an included file is just copied in verbatim.
--- foo.org
#+INCLUDE: date.org
* this is a test
--- date.org
{{{date(%d %b %Y)}}}
You want:
{{{time(%d %b %Y)}}}
{{{date}}} is used to refer to #+DATE: value, but there is none in your
example.
One more piece of information. If I move the #+INCLUDE: directive down under a
headline, then the time directive is converted. However I am trying to import
this /above/ the first headline. Is that possible ?
--
-Tim
[O] bug#14374: Possibly incorrect custom :types
Package: org-mode cus-test.el suggests the following variables may have incorrect custom :types. (There may be some false positives.) This refers to Org mode in current Emacs trunk. Eg, org-footnote-auto-adjust does not have nil as an option. org-refile-target-verify-function org-icalendar-combined-description org-link-frame-setup org-export-with-archived-trees org-bibtex-prefix org-log-note-headings org-structure-template-alist org-export-html-postamble-format org-get-priority-function org-export-odt-content-template-file org-export-latex-quotes org-export-html-toplevel-hlevel org-agenda-ndays org-export-initial-scope org-plantuml-jar-path org-export-blocks-witheld org-make-link-description-function org-export-html-postamble org-babel-lob-files org-agenda-export-html-style org-clock-heading-function org-show-notification-handler org-agenda-custom-commands org-beamer-outline-frame-options org-agenda-day-face-function org-use-fast-tag-selection org-export-docbook-xsl-fo-proc-command org-link-translation-function org-export-docbook-xslt-stylesheet org-export-docbook-xslt-proc-command org-columns-modify-value-for-display-function org-export-html-preamble-format org-agenda-auto-exclude-function org-export-docbook-doctype org-wl-namazu-default-index org-agenda-inactive-leader org-export-ascii-underline org-sparse-tree-default-date-type org-footnote-auto-adjust org-protocol-default-template-key
