From: "Charles C. Berry" <cberry@tajo.ucsd.edu>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: emacs-orgmode@gnu.org, Sunny Srivastava <research.baba@gmail.com>
Subject: Re: Re: Org-mode Code Blocks Manuscript: Request For Comments
Date: Tue, 7 Dec 2010 09:05:06 -0800 [thread overview]
Message-ID: <Pine.LNX.4.64.1012070837560.30916@tajo.ucsd.edu> (raw)
In-Reply-To: <C9225DC7-6B50-4A25-B26E-FCD0EE45D64E@tsdye.com>
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
next prev parent reply other threads:[~2010-12-07 17:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-02 19:28 Org-mode Code Blocks Manuscript: Request For Comments Eric Schulte
2010-12-02 19:36 ` Jeff Horn
2010-12-02 23:13 ` Eric S Fraga
2010-12-03 1:17 ` Thomas S. Dye
2010-12-03 12:26 ` Eric S Fraga
2010-12-03 17:29 ` Thomas S. Dye
2010-12-03 20:07 ` Eric S Fraga
2010-12-03 7:16 ` Nick Dokos
2010-12-07 22:55 ` Sébastien Vauban
2010-12-08 16:33 ` Thomas S. Dye
2010-12-08 19:55 ` Eric Schulte
[not found] ` <87bp4w0zmx.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-12-09 13:22 ` **: " Sébastien Vauban
2010-12-09 14:46 ` Eric Schulte
2010-12-09 19:48 ` Sébastien Vauban
2010-12-08 19:54 ` Eric Schulte
2010-12-03 7:58 ` Detlef Steuer
2010-12-05 6:03 ` Thomas S. Dye
2010-12-06 19:52 ` Charles C. Berry
2010-12-07 0:13 ` Sunny Srivastava
2010-12-07 4:48 ` Charles C. Berry
2010-12-07 14:24 ` Thomas S. Dye
2010-12-07 17:05 ` Charles C. Berry [this message]
2010-12-09 7:20 ` Charles C. Berry
2010-12-09 8:07 ` Thomas S. Dye
2010-12-06 2:02 ` Christopher Allan Webber
2010-12-08 19:54 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1012070837560.30916@tajo.ucsd.edu \
--to=cberry@tajo.ucsd.edu \
--cc=emacs-orgmode@gnu.org \
--cc=research.baba@gmail.com \
--cc=tsd@tsdye.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).