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
