I haven't looked into it too closely, but I would guess that when
fig=TRUE is specified, first the R block is run, and then the additional
R commands

  dev.copy2eps()
  dev.copy2pdf()
  
are run.  This results in the creation of eps and pdf files based on the
last thing plotted.  The functions could each take a file="foo" argument
(the filename defaults to Rplots.[eps|pdf]).  Sweave uses automatically
incremented names for its generated graphics files.  If your block
system could have an after-block hook, you could evaluate the original
block, then the appropriate dev.copy function, and then add an
additional line to the exported file for inclusion of the graphics file.

> However I think the rest of the point you make immediately below would
> be easily addressed through using an org-mode only approach.

Exciting!  If you're interested in what other options the Sweave
preprocessor contains, the manual can be found at
http://www.stat.auckland.ac.nz/~dscott/782/Sweave-manual-20060104.pdf.

Sweave also has a processing option called "tangle".  This extracts all
of the R code from a document and puts into its own file.  This would be
a useful feature in a generic block exporter as well, I would think.
Take all of the blocks of a certain type and dump the content into a
file with the appropriate extension for whatever the major mode was for
that block.

Finally , a couple of systems for caching Sweave output have sprung up.
I think these use the strategy of hashing the content of each block,
saving the output of each block, and only re-running the block if the
content has changed.  A general-purpose option like this for the block
exporting system in org could be very nice to have.  It's possible that
the attachment system with git integration already gets us very close to
a working version of this.

The more I think about this last possibility, the more potential I think
it has.  With the caching turned on, at export time you create files
containing the contents of each block to be cached, one file per block.
You create a second set of files that has the results of block export,
again one file per block.  You add the directory of block files and
results using org-attach.  On the next export, block files are generated
again.  You use git to ask which ones have changed.  For those that have
changed, you go on to do the normal block export, saving the results
again.  Finally, you pull the results files back into the original
document in the right places.  It would be neat if something like this
could work.

> If you happen to use yasnippets, I find it makes the creation of
> blocks in org files a very quick/easy experience.  See
> http://legito.net/worg/org-configs/index.php#sec-2.1 for details.

I'll check it out, thanks.  Sorry to ramble, hope this was useful!

Looking forward to seeing what you come up with!
/au

-- 
Austin Frank
http://aufrank.net
GPG Public Key (D7398C2F): http://aufrank.net/personal.asc