Replies: 61 comments 66 replies
-
|
Another possibility is to use the dynamic pages mechanism, which could also be used to make
I see the following upsides and downsides relative to the Roxygen approach:
@martinamorris , @mbojan , @chad-klumb , @drh20drh20 , @sgoodreau , @CarterButts , @handcock , any thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
For comparison, I imagine documentation for customised Roxygen would look something like this: #' @docType ergmTerm
#' @usage absdiff(attr, pow=1)
#' @title Absolute difference
#' @details The \code{attr} argument specifies a quantitative attribute (see \NodalAttr for details). This term adds one network statistic to the model equaling the sum of \code{abs(attr[i]-attr[j])^pow} for all edges (i,j) in the network.
#' @keywords binary, dyad-independent, frequently-used, directed, undirected, quantitative nodal attribute
InitErgmTerm.absdiff <- function(nw, arglist, ..., version=packageVersion("ergm")) {
ETC...
} |
Beta Was this translation helpful? Give feedback.
-
|
I think I Iike Roxygen more than the idea from #28 (comment). I think we can use Is the idea to still have all the terms documented on a single page, grouped somehow or each one having its own? I'm not a big fan of the current setup with one big page because its cumbersome to scroll/search through. |
Beta Was this translation helpful? Give feedback.
-
|
Roxygen API is designed for documenting functions, and it wouldn't know what to do with I am having trouble envisioning how to use Roxygen here without extensions. Can I ask you to prototype it for 2-3 terms (e.g., |
Beta Was this translation helpful? Give feedback.
-
|
Sure, I'll have a look. Are we aiming at one big page or separate ones with lots of interlinks? |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking either one big page or both. (Alternatively, the one big page could be an index page with brief term descriptions linking to separate ones.) |
Beta Was this translation helpful? Give feedback.
-
|
Or one big vignette and separate Rd files? |
Beta Was this translation helpful? Give feedback.
-
|
I like some version of both. The one big page makes searching within page easy. |
Beta Was this translation helpful? Give feedback.
-
|
There is already an In any case, I am still not sure if one can use unmodified Roxygen to get this to work. In particular, |
Beta Was this translation helpful? Give feedback.
-
The question is if user asks On the other hand if we want to have individual pages for the terms (
Right! Forgot about that.
I think I saw some code snippet somewhere with which one can dump the list of family members to Rd... |
Beta Was this translation helpful? Give feedback.
-
|
Here's what would work nicely, I think:
In other words, much of what @skyebend 's vignette does, but integrated into the R's help system and updated as more packages are loaded. If an acceptable formatting could be produced for each term using Roxygen, we can then piggyback on @skyebend 's code to scan through all the help pages with an appropriate title/keyword, parse their term information, and put them in the index using the Dynamic Pages method. This would probably give us the best of both worlds: the term writer uses Roxygen and Rmarkdown, but the end-user sees a detailed and self-updating index. Lastly, I think |
Beta Was this translation helpful? Give feedback.
-
That sounds good. WRT and so on, and indeed one will get a list of terms by each "family". I'm anyway looking into Roxygen API if there is any promising value for effort of creating our own tags. |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, it'll do more than that. According to the Roxygen2 docs, |
Beta Was this translation helpful? Give feedback.
-
|
I used it in |
Beta Was this translation helpful? Give feedback.
-
|
OK, I see how that could work. It might still make things a bit crowded, but as long as the crowing is out of the way, it shouldn't be too much of a problem. |
Beta Was this translation helpful? Give feedback.
-
|
Question for everyone, but particularly @martinamorris , @chad-klumb , how valuable would it be to have this type of documentation and indexing for the proposals? We are currently doing it for statistics, constraints, and references. |
Beta Was this translation helpful? Give feedback.
-
|
Now that the workshops are out of the way, I would like to get this across the finish line and merge. @joycecheng is working on porting other packages in the suite (with I have some further questions for discussion, that I will post in separate subthreads after this one. Again, the current draft of @martinamorris , @mbojan , @CarterButts , @handcock , @drh20drh20 , @chad-klumb , @sgoodreau |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
5. Right now, the code lists all terms it can find, even if the package is neither loaded nor attached (but is installed). Do we want that? The options I can see:
Any thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I like the whole setup a lot. I'm a bit concerned with default font size. On my machine the text in the 'term' column is very small. On the verge of readability. See this screenshot of |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that on <a href="#cat_bipartite" onclick="window.parent.helpNavigate(this.href); return false">bipartite</a>The category headers (to which these should lead, right?) don't have the proper <a id="bipartite" onclick="window.parent.helpNavigate(this.href); return false">bipartite</a>The |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the new default seems equivalent to the old "strong".
śr., 7 lip 2021, 02:28 użytkownik Joyce Cheng ***@***.***>
napisał:
… I think I am on a later version of tools and had to remove
dependencies='strong'. Looks like there was a breaking change and the
dependencies values are now different:
https://rdrr.io/r/tools/dependsOnPkgs.html
Does that still work for you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#274 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3NHV2RWBYSPZ2OZPOGSLTWONUPANCNFSM43WTXASA>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Next discussion question: Package index. Right now, the Roxygen block is parked above the
Any preferences? |
Beta Was this translation helpful? Give feedback.
-
|
@martinamorris , @mbojan , @CarterButts , @handcock , @drh20drh20 , @chad-klumb , @sgoodreau, I think we are at a point where we can begin merging this code into |
Beta Was this translation helpful? Give feedback.
-
|
Ok, it installs now on my windows machine. And I've taken a look at: They look good, but I also have suggestions about organization for the |
Beta Was this translation helpful? Give feedback.
-
|
It would also help to alias "bin" and "binary" if possible: |
Beta Was this translation helpful? Give feedback.
-
|
With the new documentation infrastructure having been merged into mainline |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
At the moment, all the
ergmterms are documented in one big file (ergm-terms.Rd) with a "standard" syntax for keywords. Porting them to Roxygen (somehow) would greatly simplify maintenance in the following ways:InitErgmTermfunction definitions, for much better maintainability.@template, common bits of text (like meanings of arguments common among many terms) only need to be written and updated once.Rdformat.AFAIK,
roxygen2has an API for custom@tags and document types, and we could write them to generate automatically formattedRdfiles. Some other things we might be able to do:@seealso-style cross-referencing for related terms.Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions