[Bioc-devel] [biocore] Sweave changes (keep.source = TRUE or FALSE?)
Friedrich Leisch
friedrich.leisch at stat.uni-muenchen.de
Wed Dec 6 11:41:43 CET 2006
[ resent to bioc-devel upon request from Seth ]
>>>>> On Tue, 5 Dec 2006 13:17:14 -0500 (EST),
>>>>> Vincent Carey 525-2265 (VC5) wrote:
>>
>> Sorry to join in late, I was travelling last week. First, let me thank
>> Duncan for his work, this really fixes one of the main drawbacks
>> Sweave had!
>>
>> Hence, I agree with Duncan and Martin in that I would like to change
>> the default in R to keep.source=TRUE. But I understand Robert that
>> testing software gets hard if the tools which are used for testing
>> change.
> It seems to me that if you are changing the API/behavior then we users have
> to adapt to that, given sufficient warning. This means that instead of
> Sweave("foo.Rnw"), I have to write Sweave("foo.Rnw", keep.source=FALSE),
> to get the former behavior, right?
Or insert \SweaveOpts{keep.source=FALSE} in the vignette or set the
global default for R via options() or whatever -> that is yet to be
implemented and one of the goals of this discussion is to see what is
the best way in terms of least work for developers.
> It may still be debatable whether keep.source=TRUE is a desirable default.
> It does propagate comments, but Sweave is supporting literate programming,
> so that comments in code are not necessarily crucial for the objective
> of the Sweave user. The document narrative is supposed to take care
> of commenting. It is also not clear to me that keeping the source
> formatting is preferable to the programmatic formatting by the interpreter
> display facility.
> So I would say there are real questions about the suitability of
> keep.source=TRUE as a default for Sweave. The availability is
> definitely nice, but the spirit and aesthetic aspects of Sweave
> use may be better supported in many cases, perhaps the vast
> majority of all documents created to date, with keep.source=FALSE.
I agree on the comments part, i.e., that comments in code chunks
should not be so much necessary as in standard R code. One exception
is inside function definitions where the can be very usefull.
Ad source formatting: If you use a smart editor with automatic
indentation etc then human formatting is better than what the machine
does in many cases (depends on the human, of course). I tend to break
lines at points where it makes sense content-wise to group arguments
of a function on one line that belong together. E.g., for a plot
statment one line contains the data, the next line all axis
annotation, etc.
>>
>> As discussed by email this summer on r-devel I want to change another
>> Sweave default for 2.5: I want to set stylepath=FALSE and include no
>> \usepackage{/path/to/Sweave.sty} by default. This means in effect that
>> each Sweave file needs to be adapted, by either inserting
>> \usepackage{Sweave} or \SweaveOpts{stylepath=true} in the header. I
>> didn't implement the changes back then because the discussion was too
>> close to feature freeze.
>>
>> I also will do some other Sweave changes over christmas break, but
>> those should all be safe, i.e., only add functionality.
>>
>> Before people now start yelling at me: We can only improve software,
>> if we are allowed to change it and/or fix behavior that can be
>> considered a bug. And the paths inserted on Windows machines in an
>> English locale are buggy (and were so ever since ...).
> In the past windows users had to do something to deal with undesirable
> latex resource path generation with Sweave, I have some recollection
> of that. Now all users have to do something to get the old
> behavior?
No. I will implement an options setting for Sweave, i.e., you define
what you want once in your .Rprofile and are done.
> Is it not possible to fix the windows path generation problem at
> the R level instead?
It is not an R problem, but a latex problem: The default path to an R
installation on an *English* windows machine (path depends on
language) is
C:\Program Files\R\...
and the blank is something latex cannot handle.
Best,
Fritz
More information about the Bioc-devel
mailing list