You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to be able to specify the order that arguments are documented when I document multiple functions with semi-overlapping arguments in the same .Rd file.
Motivating example
I have two functions documented in the same .Rd file:
#' Two functions#' @param a First argument#' @param b Second argument#' @param c Third argument#' @param ... Dots#' @param z Last argumentf1<-function(a, b, ..., z) {...}
#' @rdname f1f2<-function(b, c, ..., z) {...}
I'd like my arguments to be ordered a, b, c, ..., z in my documentation. If I document f1 before f2, I get an order of
If I flip the order of functions and document f2 before f1, I still get the wrong order:
#' Two functions#' @param a First argument#' @param b Second argument#' @param c Third argument#' @param ... Dots#' @param z Last argumentf2<-function(b, c, ..., z) {...}
#' @rdname f2f1<-function(a, b, ..., z) {...}
The only way I've found to avoid this problem is by including a dummy function that "uses" all the arguments from both functions.
#' Two functions#' @param a First argument#' @param b Second argument#' @param c Third argument#' @param ... Dots#' @param z Last argument#'#' @usage NULLf<-function(a, b, c, ..., z) NULL#' @rdname ff1<-function(a, b, ..., z) {...}
#' @rdname ff2<-function(b, c, ..., z) {...}
This yields the desired result, but the obvious drawback is my package now includes an unnecessary unexported function.
Possible solution
#258 introduced the restriction that arguments must be documented in the same order as they appear in the formals of each documented function. The current implementation forces all arguments that appear only in the second function to be documented after all arguments that appear in the first function.
I would ease this restriction so that arguments are not reordered if the subset of @param tags for each function are in the same order as that function's formals, e.g. in the above example, a, b, c, ..., z would be a valid order because the subset a, b, ..., z matches the formals of f1 and the subset b, c, ..., z matches the formals of f2. The current reordering rule would be applied if the order of @param tags isn't compatible with the order of at least one function's formals.
I'd be happy to submit a PR if you think this change makes sense.
The text was updated successfully, but these errors were encountered:
I'd like to be able to specify the order that arguments are documented when I document multiple functions with semi-overlapping arguments in the same .Rd file.
Motivating example
I have two functions documented in the same .Rd file:
I'd like my arguments to be ordered
a
,b
,c
,...
,z
in my documentation. If I documentf1
beforef2
, I get an order ofIf I flip the order of functions and document
f2
beforef1
, I still get the wrong order:The only way I've found to avoid this problem is by including a dummy function that "uses" all the arguments from both functions.
This yields the desired result, but the obvious drawback is my package now includes an unnecessary unexported function.
Possible solution
#258 introduced the restriction that arguments must be documented in the same order as they appear in the formals of each documented function. The current implementation forces all arguments that appear only in the second function to be documented after all arguments that appear in the first function.
I would ease this restriction so that arguments are not reordered if the subset of
@param
tags for each function are in the same order as that function's formals, e.g. in the above example,a
,b
,c
,...
,z
would be a valid order because the subseta
,b
,...
,z
matches the formals off1
and the subsetb
,c
,...
,z
matches the formals off2
. The current reordering rule would be applied if the order of@param
tags isn't compatible with the order of at least one function's formals.I'd be happy to submit a PR if you think this change makes sense.
The text was updated successfully, but these errors were encountered: