Hi Tom,
I think you have hit the nail on the head -- it took me ages to get org
up and running with all the extra config to generate a beamer doc. part
of the trouble in that case was that i was following emails that were a
year old, but still I think the problem you outline is clear. As to the
solution, your ideas sound sensible.
To add one extra suggestion: how about a web-service of some sort where
you upload your .org file, and it returns the 'output' (e.g. pdf doc)
produced by a native Emacs 23.X session running a stable version of org
with zero extra configuration? I realise that it may be a lot of work
to produce such a web service and expensive to maintain, but those
issues aside, having a "vanilla" system to test RR org documents on would
be great.
best wishes, Stephen
"Thomas S. Dye" <
tsd@tsdye.com> writes:
Aloha all,
I'm eager to learn how to build a self-configuring Org-mode file.
I think Org-mode is uniquely positioned to produce reproducible research
documents, but frankly speaking, the author of a reproducible Org-mode
research document would be foolish to release it. The probability that it
would run out-of-the-box on a reader's computer is quite a bit less than 1.
Multiply this fraction by the number of potential readers and the probability
that the author will receive one or more emails entitled something like "Your
reproducible research isn't reproducible" rapidly approaches 1.
A desire to produce reproducible research with Org-mode shouldn't reduce to an
open-ended commitment to solve configuration problems on users' computers
around the world. An Org-mode file that reliably self-configures might solve
this problem.
Based on the kind comments of several list members, I've come up with what I
hope are the rudiments of such a self-configuring Org-mode file. I'm
requesting your comments because I believe, individually and collectively, you
know way more about this than I do.
1) At the end of the Org-mode file are some instructions saying something like
"To use this document, first
evaluate this code block", as suggested by Dan Davison:
# Local variables:
# eval:(sbe "essential-document-config")
# End:
2) the source code block "essential-document-config" would consist of noweb
calls to Library of Babel functions:
#+source: essential-document-config
#+begin_src emacs-lisp :noweb yes
<<lob-set-this-variable(x=t)>>
<<lob-set-that-variable(x=nil)>>
#+end_src
3) The Library of Babel would be
populated with little functions, each of which sets a single variable in a buffer-local way
(as suggested several times to me on the list):
#+source: lob-set-this-variable
#+begin_src emacs-lisp :var x=nil
(set (make-local-variable 'this-variable) x)
#+end_src
4) A super-function in the Library of Babel would set the buffer-local
instance of every relevant Org-mode variable to its default state:
#+source: lob-set-local-defaults
#+begin_src emacs-lisp
...
#+end_src
5)
The Org-mode community would be responsible for populating the Library of Babel with the relevant little functions--whenever a new configuration variable is introduced, then a little function for it would be deposited in the Library of Babel.
The name of the configuration function would be part of the variable's
docstring.
6) The author of a reproducible Org-mode document could reasonably expect to
produce a document that self-configures on computers around the world, in a
way that is safe and effective. The author would call the super-function,
then add noweb calls to little functions until the reproducible research
document works as expected.
I'm happy for any comments, positive or negative.
All the best,
Tom
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode