From ggrothendieck at myway.com  Mon Aug  2 16:07:22 2004
From: ggrothendieck at myway.com (Gabor Grothendieck)
Date: Mon Aug  2 16:07:30 2004
Subject: [Rd] directing print.packageInfo to a file
Message-ID: <20040802140722.9B7FB39C1@mprdmxin.myway.com>


From:   	Kurt Hornik <Kurt.Hornik@wu-wien.ac.at>

>>>>> Gabor Grothendieck writes:

>
> I already suggested using the pager as a workaround
> in the original thread although your pager workaround
> has the advantage of being 100% in R while mine used
> a batch file which defined a new pager.
>
> Note that R already supports
>
> options(pager = "console")
>
> but if you do this then it seems that capture.output
> still won't capture it. Thus one alternative solution
> would be to get capture.output to work with
> pager = "console" and modify print.packageInfo to
> take a pager= argument which it would pass down to file.show.
> (file.show already has a pager argument.)
>
> Then one could write:
>
> capture.output( print.packageInfo(help(package = chron),
> pager = "console"), file = "myfile.txt")
>
> That gets it down to one line although it still seems
> unnecessarily indirect when one could just write:
>
> print.packageInfo(help(package = chron), file = "myfile.txt")
>
> if print.packageInfo just had a file= argument.
> Furthermore, print.packageInfo ALREADY creates the file as a
> temporary file to hand over to file.show so its not much of
> a stretch to give the user access to what it is already
> creating anyway.

The point about the proferred solution is that it works generally when
is is desired to capture output that is "printed" via file.show(). If
we start adding extra arguments to print.packageIQR (which is documented
to be internal, btw), we would need to do the same for print.libraryIQR
and print.hsearch and ..., i.e. for all print() methods which in fact
display something using file.show() as a "side effect". That seems
suboptimal to me, when one can wrap the above in a very simple and
generally applicable function (and just calling the print() generic
rather than some method, btw).

---

That's a good point but if a command _already_ produces a file 
I think its logical that access to that file be given directly, 
even if that means having to add a file= argument in many commands.   
In my opinion, both our pager workarounds are too complex/geeky 
for a simple task.

I think this whole thing could be streamlined by extending the
pager= option to accept a connection, e.g.

           options(pager = file("a.txt"))

and then modifying the args of file.show to:

function (..., header = rep("", nfiles), title = "R Information", 
  delete.file = FALSE, file, 
  pager = if (missing(file)) getOption("pager")) else base:file(file))

Now passing down the ... arguments from print.packageInfo
to file.show only involves a one line change, namely, just
add three dots at the end of the call to file.show within
print.packageInfo:

    file.show(outFile, delete.file = TRUE, title = 
        paste("Documentation for package", sQuote(x$name)), ...)

and this automatically gives pager= and file= support to it.
(Note that currently the three dots are already in the arg list to print.packageInfo but are not used anywhere in the body of that
function.)  Modifying the other functions might be just as easy.

Also, while we are at it we could add pager= arguments
to sink and to capture.output.  With the above any of the following
would work:

   print.packageInfo(help(package = chron), file = "a.txt")

   print.packageInfo(help(package = chron), pager = file("a.txt"))

   capture.output(help(package = chron), pager = file("a.txt"))

   sink(pager = file("a.txt"))
   help(package = chron)
   sink()

   oop <- options(pager = file("a.txt"))
   help(package = chron))
   options(oop)


[Rd] directing print.packageInfo to a file
Gabor Grothendieck