Skip to content

Rd files

3 messages · Brian Ripley, Douglas Bates, Friedrich Leisch

Original
Brian Ripley
# 
understand
guess
It's legal with S's files, and it is a great way to avoid file name
problems: just have one file with a simple name (and some of those
in lme and locfit cause problems to several tools: file names with "<" in
are somewhat unexpected!)  However, S has an end of section marker, and
it think that is needed for safety. (In S format, help for one object is
between .BG and .WR.)
Douglas Bates
# 
>> From: Paul Gilbert <pgilbert@bank-banque-canada.ca> > From Fritz
  >> Leisch

  >> >Yes, currently the idea is to have one Rd file per html/help
  >> file. I >never thought about it though ... do many people want to
  >> be able to >have all documentation in one big file?
  >> 
  >> I don't really care too much about this, I just wanted to make
  >> sure I understand
  >> it. However, it may not be too difficult allow a large .Rd file
  >> and have the build decompose it using the /name{..}. I currently
  >> keep many functions in one file along with their documentation
  >> separated by /* */. I separate this into the .R and .Rd files
  >> with an awk script. So the question for me is whether I have to
  >> separate the .Rd file further or is the R build going to do it. I
  >> guess I would prefer that the R build do it, as I think others
  >> may use it this way too, but I think I can do it fairly easily.

  BDR> It's legal with S's files, and it is a great way to avoid file
  BDR> name problems: just have one file with a simple name (and some
  BDR> of those in lme and locfit cause problems to several tools:
  BDR> file names with "<" in are somewhat unexpected!)  However, S
  BDR> has an end of section marker, and it think that is needed for
  BDR> safety. (In S format, help for one object is between .BG and
  BDR> .WR.)

The .Rd file name in lme that always gives me trouble is [.pdMat.Rd.
I hadn't realized that the others with "<" in them, like matrix<-.Rd,
also gave problems.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Friedrich Leisch
# 
BDR> It's legal with S's files, and it is a great way to avoid file
BDR> name problems: just have one file with a simple name (and some
BDR> of those in lme and locfit cause problems to several tools:
BDR> file names with "<" in are somewhat unexpected!)  However, S
BDR> has an end of section marker, and it think that is needed for
BDR> safety. (In S format, help for one object is between .BG and
BDR> .WR.)

DB> The .Rd file name in lme that always gives me trouble is [.pdMat.Rd.
DB> I hadn't realized that the others with "<" in them, like matrix<-.Rd,
DB> also gave problems.

Does S also store the complete output in one file or is the output
split into different files? 

In the second case we'd simply move the problem from problematic input
names to problematic output names ...

Anyway, what we need is a safe method of seperating file names from
function names. As this is platform-dependent we might do the
following:

output filenames are passed through an OS-dependent safety checker,
which replaces special characters by some unique identifiers, the
mapping alias <-> file is done using an index file anyway. this would
work very much like the current 8.3 conversion, just that it leaves
most file names untouched.

adding another platform then just amounts to adding another function
which should be the cleanest way of doing it.

the one-input-file thing is trivial, so I'll plan to do it in any
case.

.f




-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._