Re: Babel, Python and UTF-8

From: Dan Davison <dandavison7@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Vincent Beffara <vbeffara@ens-lyon.fr>, emacs-orgmode@gnu.org
Subject: Re: Babel, Python and UTF-8
Date: Mon, 06 Dec 2010 09:42:58 +0000	[thread overview]
Message-ID: <87d3pfjkyl.fsf@gmail.com> (raw)
In-Reply-To: <87mxokz176.fsf@gmail.com> (Eric Schulte's message of "Sun, 05 Dec 2010 08:30:53 -0700")

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Vincent Beffara <vbeffara@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