Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation #8

Closed
Dasonk opened this issue Apr 15, 2014 · 3 comments
Closed

Documentation #8

Dasonk opened this issue Apr 15, 2014 · 3 comments

Comments

@Dasonk
Copy link

Dasonk commented Apr 15, 2014

I just found this via this SO question and it caught my eye. I think this is a nice idea and would make it a lot easier for people to wrap up their useful functions without the overhead of making a package. I've been interested in that idea for a while and one thing I did work on was creating help files for functions that aren't in a package - some of that work is here: https://github.com/Dasonk/flydoc

The solution I have isn't complete - I had a working case of using all of the first comments after the function declaration as the description for the help file but I wasn't in the habit of regularly pushing my commits and ended up losing some of that.

My question for you is how did you envision the 'help documentation' is stored in the users source files? This is your package but I'm interested in helping by forking and getting some of this functionality down but want to know what you had envisioned for that.

@r2evans
Copy link

r2evans commented Apr 16, 2014

I also saw this package in the same SO question. I'd argue that using roxygen2 would capitalize on a lot of roxy-to-Rd conversions. As far as how to call it, I think something similar to Hadley's devtools would work, where utils::help is masked by devtools:help, which checks to see if it's a devtools-installed help file and falls back to utils::help otherwise.

@klmr
Copy link
Owner

klmr commented Apr 16, 2014

Like @r2evans, I think the right way is to use established tools – i.e. roxygen2. And yes, I’ll probably copy devtools’ mechanism of hooking into help, although I would have preferred if R provided a direct way of attaching documentation (or other meta data) to a function, instead of having to patch core functions.

With that in mind, I actually like flydoc’s approach of making such meta information accessible at runtime. This won’t be the priority but it’s definitely “nice to have”.

@klmr klmr added the question label Apr 16, 2014
@klmr klmr added this to the Support infrastructure for modules milestone May 6, 2014
@klmr klmr modified the milestones: Support infrastructure for modules, Interactive documentation support Aug 13, 2014
@klmr
Copy link
Owner

klmr commented Aug 15, 2014

The work for this is currently being done in the branch help. I’m closing this issue for now. Further discussion should take place in #32, or in dedicated issues.

At the time of writing, a rudimentary system of the interactive help works (modulo the issues already reported). I won’t push it into master yet until these issues are resolved.

@klmr klmr closed this as completed Aug 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants