Re: [Orgmode] Re: Org-mode Code Blocks Manuscript: Request For Comments

[Charles C. Berry]

On Tue, 7 Dec 2010, Thomas S. Dye wrote:

> Aloha Chuck,
> On Dec 6, 2010, at 6:48 PM, Charles C. Berry wrote:
>
> > On Mon, 6 Dec 2010, Sunny Srivastava wrote:

{snip]

> > I posted the vanilla version of the file at
> >
> > http://famprevmed.ucsd.edu/faculty/cberry/org-mode/RpkgExample.org
> >
> > It has the src blocks I use in each package.
> >
> > To use it, you set up a minimal package directory structure:
> >
> >  myPackage/
> >  myPackage/DESCRIPTION
> >  myPackage/man/
> >  myPackage/R/
> >
> > say, and (optionally) put it under version control.
> >
> > Or use an existing package you are already working on.
> >
> > Or download one from CRAN, and untar it.
> >
> > Then copy RpkgExample.org to myPackage/
> >
> > (or whatever the equivalent directory is)
> >
> > and you are ready to start.
> >
> > FWIW, if I have a good idea of what I am doing at the outset, I will
> > write functions in R/*.R files and create man/*.Rd files using
> > prompt() and then edit them, and then get around to checking,
> > installing, and trying out the package from the org file.
> >
> > But usually, I have only a fuzzy idea of what how to organize the
> > code, so I start by writing a snippet of code in an R :session src
> > block that sets up some objects of the sort I would want my package to
> > work on. I run that block. Then I might write a script in another :session
> > src block to do some of the work I want the package to do, and
> > try it out. Once it works I wrap it into a function, and write another
> > : session src block to call the function. Once that works, I kill the
> > src block with the function in it and yank it into a fresh buffer
> > where it is saved as R/whatever.R. After using prompt() to make the
> > man/whatever.Rd and editting it, I am ready to run the package check,
> > install the package, restart my R session and load the package. Then I
> > can stitch together tests, examples, and more functions in the org
> > file, and test them and migrate them to the right places.
> >
> >
> > Comments welcome.
>
> Thanks for sharing this.  It looks useful.  Would you consider putting it on 
> Worg with the other babel source block examples?

Yes. I will clean it up a bit in the coming days and post it.


> Have you thought about tangling the .R files directly from the Org-mode 
> buffer?  With :tangle R/whatever.R you might save yourself having to kill the 
> source block, yanking it to a fresh buffer, and saving.

Well, yes and no. (There was a brief discussion of just his issue here
a couple of months back.)

I kinda assumed that the workflow would be a bit more awkward with the
package files all held in the org file:

  - run a test, find a bug
  - move to find src block with relevant .R or .Rd code
  - edit the .R or .Rd
  - tangle all the src blocks containing package code or files
  - check and/or install and then load the package
  - move back to the test src block
  - repeat

I was thinking that navigating thru the org file to find the .R or .Rd
src block and later back to the test src block would be slower than
jumping between a few code buffers, but maybe I overlooked the power
of folding, TODO's, and other org-built functionality. The speedbar
makes navigating the package directory pretty easy, but I suppose that
it could be used exclusively on the org file. I'll think a bit more
about this.

Also, I was thinking that tangling the whole package every time I
change a line of code is a bit over the top, but again maybe I should
just try it and see. Also, I suppose I could mark blocks that are not
under revision as ':tangle no' to suppress tangling them. If there is
an easy way to set the tangle arg to a filename if point is in the src
block or subtree and 'no' otherwise, that might make tangling just a
newly changed block easier.


Chuck

> My goal when designing these things, which might or might not appeal to you, 
> is to hold the entire project in the Org-mode file.  In the end, exporting 
> the Org-mode file to html or pdf can yield a rich description of the project, 
> independent of its product, man files, etc.  Later, when I want to make 
> changes, I know exactly where to go.
>
> All the best,
> Tom
>
> > Best,
> >
> > Chuck
> >
> >
> > > Your help is highly appreciated.
> > > 
> > > Thank you in advance.
> > > 
> > > Best Regards,
> > > S.
> > > 
> > > On Mon, Dec 6, 2010 at 2:52 PM, Charles C. Berry 
> > > <address@hidden>wrote:
> > > 
> > > > On Sat, 4 Dec 2010, Thomas S. Dye wrote:
> > > > 
> > > > Aloha Detlef
> > > > > 
> > > > > On Dec 2, 2010, at 9:58 PM, Detlef Steuer wrote:
> > > > > 
> > > > > Hi!
> >
> > [rest deleted]
> >
> >
> > Charles C. Berry                            Dept of Family/Preventive 
> > Medicine
> > address@hidden                      UC San Diego
> > http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

Charles C. Berry                            Dept of Family/Preventive Medicine
address@hidden                      UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901