search

cameronbracken / pgfSweave

Quality graphics and speedy compilation with Sweave
http://r-forge.r-project.org/projects/pgfsweave/
29 stars 6 forks source link

Pass options through Sweave() #36

Open halpo opened 12 years ago

halpo commented 12 years ago

This call is acceptable with Sweave with both driver=RWeaveLatex() and driver=cacheSweaveDriver

Writing to file simple-illustration.tex
Processing code chunks with options ...
1 : term hide (label = sectionsetup)

but throws an error when using a driver=pgfSweaveDriver

Error in driver$setup(file = file, syntax = syntax, ...) : 
  unused argument(s) (prefix.string = "figures/fig")```

This is in general way of specifying global options without having to include a line in the file.  Please add the support for specifying options in this way.
halpo commented 12 years ago

I believe that it is related but pgfSweave also does not allow for setting the prefix.string by the environment variable SWEAVE_OPTIONS. I think that this might be because the driver itself does not accept prefix.string as an option.

yihui commented 12 years ago

Well, a more general problem is I believe the design of Sweave itself is essentially not friendly to extensions like cacheSweave or pgfSweave; issues of incompatibility like this will come out sooner or later -- when package authors have to copy the hundreds of lines of code in RweaveLaTeX(), compatibility is almost doomed...

After being frustrated for many times on issues like this, I decided to rewrite another engine, and now I'm close to release a beta version; maybe it is still too early to tell, but anyway here is an incomplete introduction: https://github.com/yihui/knitr

halpo commented 12 years ago

yihui, as fantastic a programmer you are I don't think that another version/fork is what we need. What would be really great is if the Authors worked collaboratively on a single project, as should be the spirit of open source. cacheSweave, pgfSweave, weaver, highlight, etc. are all doing their own thing and they all have great things to contribute, but it would be so much better if we all got on the same page and make one be all end all Sweave package.

To address the specific concern I think it is actually a trivial fix of adding ... to the pgfSweaveSetup function. I've been playing around with it and that seems to fix it. I'm not sure if it was an omission or intentional to restrict the carry though arguments.

yihui commented 12 years ago

To be clear, I totally respect the work of Sweave; it was an amazing invention. I just do not agree with parts of its design. For example, pgfSweave should have been an option tikz=TRUE with a small function telling Sweave how this option should be handled, or cacheSweave should have been an option cache=TRUE with a set of functions which are independent of Sweave to handle cache, or highlight should be highlight=TRUE... I agree we should work collaboratively on a single project, given that the project can be decomposed into modularized parts, on which each author can contribute something. The fact with Sweave is that you have no choice but to copy a huge RweaveLaTeX() and begin to hack on it. This is not good for package authors, because it brings non-trivial burden to maintain their hacked RweaveLaTeX with the official version. Yes the fix is trivial in this case, but what was the reason behind it?

I really hate to invent my own version (it is not a fork; I redesigned and wrote almost from scratch), but I do not want to read the source code in utils/R/Sweave.R for the 100th time. I have thought about this for many times in the past few years, and tried to discourage myself from doing the "obviously wrong" thing, especially I know very well that Sweave is a sensitive topic, and my action of writing another package is likely to be interpreted as some sort of denial to Sweave, but the fact is not. I will try to make it compatible with Sweave, but also go further to allow full extensibility, which I believe will take forever to appear in official R (think how many years we have waited for the support of other graphics devices beside pdf and postscript). You may not feel convinced at the moment, since I have not started writing examples yet.