roxygen

A simple example is that I have created an extension to show , which is a S4 base method. I don't want to cause a disambiguation fork by re-documenting show in my package, and I also want to consolidate the documentation of my extension to show in the documentation for the new class, myPkgSpClass , by adding an alias for show,myPkgSpClass-method . #' @export #' @aliases show,myPkgSpClass-method #' @rdname myPkgSpClass-class setMethod("show", "myPkgSpClass", function(object){ show(NA) }) The problem I'm having, is that this results in an serious warning during documentation-build by roxygen2,

I have a function that does nothing more than ads a unique attr to any R object. Base demo: #' Setter function #' @param x an R object #' @param value a character value to set #' @export `foo<-` <- function(x, value){ attr(x, 'foo') <- value return(x) } This works like a charm except for generating a good Rd file, relevant part: \usage{ foo(var, value) <- value } And of course it triggers a warning while running R CMD check as it should be foo(var) <- value . Any hints would be really apprecieted! Update : thanks to richierocks it seems there is a fix You can use the roxygen tag @usage Here is

I've just started playing around with the roxygen package and I've very happy with the results so far. However I was wondering, is there a way to specify to roxygen that it should ignore certain functions that are not user-accessible? Specifically, I'd rather not have a .Rd file pop up because I'm using the .onLoad() hook in my package. This function is already documented in the base package so there's no reason for me to re-document it. Well, I finally found and browsed the Roxygen-devel list at R-forge to see when this would be implemented, and it appears to already be in the version of

I find R documentation to be important but also time-consuming to create/maintain. Has anyone used Roxygen yet, and if so, does it help in maintaining an R package? I've used Doxygen in the past, but those projects didn't have the man structure that R packages require. You can find the vignette here . Yes, I use it all the time (in five packages and counting). It's fantastic! With it I managed to create a complete R package (stringr) in about five hours. I recently submitted a patch to get a 10-fold speed up, which makes it even nicer to use. I'd like to start using it, but as far as I know it

Does RStudio support any automated roxygen template creation? In Emacs-ESS, C-x C-o will produce an roxygen template for a function. For example, it will automagically convert this: foo <- function(x,y) x+y into this: ##' .. content for \description{} (no empty lines) .. ##' ##' .. content for \details{} .. ##' @title ##' @param x ##' @param y ##' @return ##' @author David foo <- function(x,y) x+y Does similar functionality exist within RStudio? updates as of ESS 12.09-2 , the command has been changed to C-c C-o C-o this feature has been implemented in Rstudio: CTRL+ALT+SHIFT+R (Converting

I am new to roxygen and am struggling to see how to be able to use it to quickly create a new/custom package. I.e. I would like to know the minimum requirements are to make a package called package1 using devtools , roxygen2/3 so that I can run the commands require(package1) fun1(20) fun2(20) to generate 2000 and 4000 random normals respectively So lets take the simplest example. If I have two functions fun1 and fun2 fun1 <- function(x){ rnorm(100*x) } and fun2 <- function(y){ rnorm(200*y) } the params are numeric, the return values are numeric. I'm pretty sure this isn't an S3 method, lets

Background I written an R package, and now a collaborator (recent CS grad who is new to R) is editing and refactoring the code. In the process, he is dividing up my functions into smaller, more generic functions. What he is doing makes sense, but when I started with package.skeleton() , I had one file per function. Now, he has added functions on which the primary function depends, but that may have limited use outside the function itself. He suggests that all the functions go into a single file, but I am against that because it is easier to do version control when we work on different files. I