From: Andreas Leha <andreas.leha@med.uni-goettingen.de>
To: emacs-orgmode@gnu.org
Subject: Re: Write org variables into own R environment instead of .GlobalEnv
Date: Tue, 18 Mar 2014 22:10:30 +0100 [thread overview]
Message-ID: <87siqfciwp.fsf@med.uni-goettingen.de> (raw)
In-Reply-To: m28us78uab.fsf@krugs.de
Hi Rainer,
Rainer M Krug <Rainer@krugs.de> writes:
> Hi
>
> I just send a patch which changes the behaviour of how org variables are
> treated in R. At the moment, org variables are simply stored in the
> .GlobalEnv which means, that all show up in the variable listing (which
> can get cluttered when having many variables), they can accidentaly be
> deleted and not be restored from within R and saving all the variables
> into from R to make them available after tangling is not that easy.
>
> Therefore the patch writes the variables into their own environment
> (which I simply called org) and locks the environment and the
> bindings. This means, that the actual variable values are always in the
> environment and can not be accidentally deleted. As the environment is
> attached to the search path, they are accessible as before, but they do
> not clutter the workspace and do not show up separately e=when using
> ls() to list the contents of the workspace. When using ls(org) all can
> be seen.
>
> They can still be "overwritten", but but this only creates a new
> variable of the ame name in the .GlobalEnv which is simply hidint the
> original variable passed from org. The original variable can be accessed
> via org$VARIABLENAME. When removing the defined variable VARIABLENAME
> via rm(VARIABLENAME), the value passed from org is back.
>
> In addition, all variables can be easily be saved to disk by using
> save(org, file="/PATH/TO/FILE.Rdata") and reloaded with
> (load("/PATH/TO/FILE.Rdata")). This mechanism could actually be included
> into tangling as the default mechanism to load the variables to avoid
> cluttering the code with all the assignment commands of the org
> variables.
>
> The patch is not yet extensively tested.
> Please provide some feedback about the idea and implementation,
Currently I lack the time to test the patch. So, this is just a
(not-so-helpful) feedback on the idea: Seems to be very good!
Regards,
Andreas
prev parent reply other threads:[~2014-03-18 21:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-18 14:18 Write org variables into own R environment instead of .GlobalEnv Rainer M Krug
2014-03-18 21:10 ` Andreas Leha [this message]
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=87siqfciwp.fsf@med.uni-goettingen.de \
--to=andreas.leha@med.uni-goettingen.de \
--cc=emacs-orgmode@gnu.org \
/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).