From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: are babel python sessions and inlined images incompatible?
Date: Fri, 26 Apr 2013 15:21:36 +0200 [thread overview]
Message-ID: <86bo911l7j.fsf@somewhere.org> (raw)
In-Reply-To: m138uefueg.fsf@poto.westell.com
Hi Thomas,
Thomas S. Dye wrote:
> "Sebastien Vauban" writes:
>> Well, I *now* know it's not described in the Org manual...
>>
>> ╭──── http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01181.html
>> │
>> │ - :results graphics makes the list even longer, yes? :-) I'm not
>> │ sure that every language supports it and I don't believe it's
>> │ currently in the manual.
>> ╰────
>>
>> Though, it's described in many different posts on this ML, and in some
>> tutorials on Worg...
>>
>> ╭──── http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
>> │
>> │ If a :file filename.ext header argument is provided to an R source block, then
>> │ the output from the source block will go to the named file. What that output
>> │ is depends on the value of the :results header argument.
>> │
>> │ If the value is :results graphics then "base" graphics output is captured on
>> │ disk, and a link to the graphics file is inserted into the Org Mode buffer (as
>> │ is also the case with the graphics-only languages such as gnuplot, ditaa, dot,
>> │ and asymptote.)
>> ╰────
>>
>> I thought it was a "core" option value for all general-purpose languages (e.g.
>> emacs-lisp, python, R, ruby, sh), required when your code block outputs a
>> graphics.
>>
>> After checking, I only found it in those files:
>>
>> ./ob-maxima.el:117: (and (member "graphics" (cdr (assq :result-params params)))
>> ./ob-octave.el:272: (and (member "graphics" (cdr (assq :result-params params)))
>> ./ob-R.el:234: (and (member "graphics" (cdr (assq :result-params params)))
>
> The language documentation on Worg, such as
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html, is
> meant to be documentation, rather than tutorial. It is structured this
> way so the manual doesn't need to be updated every time support for a
> new language is added, or changes are made to a language-specific file.
>
> The template for this documentation includes a slot for default header
> arguments and also one for language-specific header arguments, because
> these are often changed by the language-specific modules.
>
> I think the hope and expectation is that the user community take over
> the tasks of creating and tending the language-specific code. If
> :results graphics makes good sense for Python, then users should feel
> free to add it to ob-python.el. With the examples you point out, it
> shouldn't be too difficult.
As you say, I guess that one could copy/paste the code from maxima, octave or
R to get the desired results.
Would we want to abstract the above, I guess we should generalize the
languages families as:
- graphics-only languages (ditaa, dot, gnuplot, etc.)
- general-purpose languages with graphical capacities (R, maxima, octave...
and, at least, python[1] IIUC)
- general-purpose languages without graphical capacities (sql, sh, etc.)
Maybe that would allow to have sets of header arguments (or default values)
mapped onto those families.
Best regards,
Seb
[1] Never used it.
--
Sebastien Vauban
next prev parent reply other threads:[~2013-04-26 13:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 4:10 are babel python sessions and inlined images incompatible? Rodrigo Amestica
2013-04-23 13:29 ` Eric Schulte
2013-04-23 22:17 ` Rodrigo Amestica
2013-04-24 21:06 ` Sebastien Vauban
2013-04-24 23:33 ` Rodrigo Amestica
2013-04-25 7:40 ` Sebastien Vauban
2013-04-25 16:27 ` Thomas S. Dye
2013-04-26 13:21 ` Sebastien Vauban [this message]
2013-04-26 22:13 ` Rasmus
2013-04-27 6:27 ` Achim Gratz
2013-04-27 6:40 ` Sebastien Vauban
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86bo911l7j.fsf@somewhere.org \
--to=sva-news-d0wtavr13harg/idocfnwg@public.gmane.org \
--cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).