From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: Babel, Python and UTF-8 Date: Mon, 06 Dec 2010 09:42:58 +0000 Message-ID: <87d3pfjkyl.fsf@gmail.com> References: <87fwuhas6t.fsf@gmail.com> <80bp54a693.fsf@missioncriticalit.com> <87hbew7yvi.fsf@gmail.com> <80k4jsszq4.fsf@missioncriticalit.com> <8739qf2ade.fsf@gmail.com> <87mxokz176.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=38787 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPXbF-0000gG-4T for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 04:43:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPXbB-00020K-3P for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 04:43:12 -0500 Received: from markov.stats.ox.ac.uk ([163.1.210.1]:61145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPXbA-0001xm-Sb for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 04:43:09 -0500 In-Reply-To: <87mxokz176.fsf@gmail.com> (Eric Schulte's message of "Sun, 05 Dec 2010 08:30:53 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: Vincent Beffara , emacs-orgmode@gnu.org "Eric Schulte" writes: > Vincent Beffara 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 .=3D "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 =3D "=C3=A9" >> #+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") :retur= n s > s =3D "" > #+end_src > > Note that as written this will return the following python error > > Traceback (most recent call last): > File "", line 2, in > 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