Suggestion: Allow for a dense usage section

[J-Moravec]

Problem:

I have a bunch of function with a large (8) number of arguments. Since the width of the arguments is larger than 80, the arguments are placed on a new line in the documentation generated by roxygen.

I have also a bunch of function with a similar number of arguments that share most of the arguments (in fact they are just wrappers around the above function). Each of them also have arguments placed on new line in the documentation.

The most logical way to group these functions is together, since they are derived from the main function, they share the same documentation, there is little reason to divide them.

The issue stemming from this is that for some 8 functions in total, each with 6-8 arguments, that is a huge block of 48-64 lines of repeated arguments on newline. And that looks plain ugly.

Possible solutions

a) If g is wrapper around f, do g = function(...) f(..., arg5 = "goo"). But imo that makes g less readable, one cannot see what parameters to pass through inspecting the signature alone.

b) Keep g(arg1, arg2, arg3), but write a custom documentation that would say just g(...). That will leave the signature in a good state, but make the documentation less clear, especially since it is not clear that arg5 = "goo". Also some roxygen2 black magic, possibly handwriting the usage section?

c) Modify roxygen2 to allow another dense style, a similar style is often used in base R, with multiple parameters being on the same line. Perhaps this is possible with roclet(), but if I am reading the documentation correctly, if it is possible with roclet, I would need to reimplement most of rd-usage.R (eh, copy paste and change the wrap_usage function).

The functions in question are rblast/blast.r, with the Rd files here.

Pointers on magic roxygen2 commands that I overlooked or hints for roclet solution are greatly appreciated.

Previously discussed.

Previously, a similar issues that mentioned a this idea was #1624, but was closed with a comment about documenting many different functions in the same file being bad style in the first place. While I agree with this sentiment, in this case it wouldn't make any sense to divide the functions into different files & documentations.