emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Charles C. Berry
Subject: Re: [Orgmode] Re: Org-mode Code Blocks Manuscript: Request For Comments
Date: Tue, 7 Dec 2010 09:05:06 -0800

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]