Switch from Rd_content/Rd_doc → Rd

[flying-sheep]

also adds test and renames parse_rd to parse_topic

fixes #109

[hadley]

I think you could replace this entire block with

rd[] <- lapply(rd, set_classes)

[flying-sheep]

will do

[hadley]

Otherwise looks good (although you need a merge/rebase)

[flying-sheep]

oh this was fast! i just rebased

[flying-sheep]

does that look good? (i added set_class(rd) as return line)

[flying-sheep]

but we have to add more tests first: i think i’ll have to think about this more…

[hadley]

See #118 - I was thinking that a baseline set of regression tests would be to run staticdocs on itself and check into /docs

[flying-sheep]

yes.

my basic idea ATM is to only rely on all the added classes internally. everything exposed to the user (e.g. exported print and to_html methods) accepts plain Rds just as returned from utils::parse_Rd.

this removes the ability to print subsets of Rds to the console, though.

I.e. user-facing methods return something like this, but also accept plain Rds and make sure internal functions get something like this:

Rd, list
|- COMMENT, character
|- arguments, list
|  |- ...
|- ...

---

alternatively i take back most changes, and just ensure that full Rds are converted to Rd_doc and have no Rd_content class, while all tags retain their Rd_content class.

this would be in line with your initial vision, but we’d need to make sure all user-facing methods are implemented for Rd as well (by simply converting Rd to Rd_doc).

I.e. pretty much your current structure, only less buggy:

Rd_doc, Rd, list
|- Rd_content, COMMENT, character
|- Rd_content, arguments, list
|  |- ...
|- ...

what do your think?

[hadley]

Thanks for these ideas — I'm implementing at the moment as part of an almost complete rewrite of the html translation system

[flying-sheep]

OK, great! Then we can close this, right?