"Eric Schulte" <schulte.e...@gmail.com> writes: > Vincent Beffara <vbeff...@ens-lyon.fr> writes: > >> Hi, >> >>>> (and it would be excellent to allow for a code block as a preamble, >>>> instead of a string in the header or as an alternative, because >>>> preambles once they are allowed tend to grow uncontrollably ;->) >>> >>> This is currently possible using the `sbe' function. Arbitrary emacs >>> lisp can be placed inside of header arguments, and the `sbe' take the >>> name of a code block and returns its result.
This makes me think of another good use of the sbe ("src block eval") function. I'm often seeing Org documents with a src block like this, #+source: essential-document-config #+begin_src emacs-lisp ;; some essential document-specific configuration #+end_src and some instructions saying something like "To use this document, first evaluate this code block". This can be automated by using sbe in a local variables line at the end of the Org file: # Local variables: # eval:(sbe "essential-document-config") # End: When the file is first opened, Emacs will evaluate the set-up blocks (after asking for confirmation). This isn't restricted to configuration of Emacs variables with emacs-lisp blocks; eval lines could reference blocks in any language, for example to start an ESS session and run some preparatory code, etc, e.g. #+source: document-config #+begin_src emacs-lisp (set (make-local-variable 'org-edit-src-content-indentation) 0) #+end_src #+source: start-ess #+begin_src R :session *R session* a <- 1 #+end_src # Local variables: # eval:(sbe "document-config") # eval:(sbe "start-ess") # End: Dan >> >> Very cool ! That does all I want, thanks for the info. For multi-line it >> is a bit heavy to write, with lots of \n and preamble .= "lskjd", but I >> can live with that. Unless there is a way already to write something >> like this ? >> >> #+source: my-preamble >> #+begin_src python :return preamble >> # -*- coding: utf-8 -*-" >> import os,sys,whatever >> #+end_src >> >> #+begin_src python :preamble (org-babel-get-and-expand-source-code-body >> my-preamble) :return s >> s = "é" >> #+end_src >> >> There is org-babel-get-src-block-info but it looks at the block around >> (point), not by name ... so I guess it would not be too hard to write >> the extraction method, but it might be somewhere in the code already. >> > > Yes, the following uses an internal Babel function, but is probably much > simpler > > #+results: my-preamble > : # -*- coding: utf-8 -*- > : import os,sys,whatever > > #+begin_src python :preamble (org-babel-ref-resolve "my-preamble") :return s > s = "" > #+end_src > > Note that as written this will return the following python error > > Traceback (most recent call last): > File "<stdin>", line 2, in <module> > ImportError: No module named whatever > >> >>>> One naive question : why is the code path different for tangling and >>>> evaluation ? One would think that a natural way for evaluation would be >>>> to tangle the current block (plus included noweb stuff etc) into a >>>> temporary file and eval that file ... and that would enable shebang for >>>> evaluation as well. There must be something I am missing here. >>> >>> Tangling works for *any* programming language, even those which have yet >>> to be created and have no explicit Emacs or Org-mode support, this is >>> because on tangling the code block is simply treated as text. >> >> As far as I understood from testing, tangling does adapt to the language >> (at least to implement :var in a suitable way), so I was under the >> impression that evaluating could be implemented as some kind of wrapping >> around the tangled output - and obviously the wrapping would have to be >> language-specific even if for the most part the tanglong is not. >> > > Yes, some language specific features (e.g. variable expansion) can be > used by the tangling mechanisms if such features are defined for the > language in question, however tangling can be done in the absence of any > language specific features and thus works for any arbitrary language. > > That shebang and preamble should remain separate for the other reasons > mentioned in my previous email. > >> >> I am just discovering all of this, sorry if I have horrible >> misconceptions about the thing ... >> > > No problem, it is a fairly (but I don't think overly) complex system. > >> >> Regards, >> >> /v >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 _______________________________________________ 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