Re: Re: Org-mode Code Blocks Manuscript: Request For Comments

["Charles C. Berry" <cberry@tajo.ucsd.edu>]

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 
>> > <cberry@tajo.ucsd.edu>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
>> cberry@tajo.ucsd.edu			    UC San Diego
>> http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901
>> 
>> 
>
>

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