Sebastien Vauban writes: > 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.)
This is something of a non-starter as all generalizations are false. Babels notion of graphics is simply that after execution of the source block it expects to be able to find a file that looks like it has a graphics format in it (and its notion of results is that it gets something from standard output that conforms to certain rules that are changeable by header arguments). A "graphics-only" language would be one that could only write files, but Babel can easily transcend that limitation and pretend it had gotten a result instead. It might even filter the result to convert between formats. Conversely, a language that cannot write files could have an implementation where Babel constructs the file to put in the graphics link in Org from the output of the program. Existing Babel language implementations already use both mechanisms. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
