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
next prev parent reply other threads:[~2010-12-06 9:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 23:50 Babel, Python and UTF-8 Vincent Beffara
2010-12-02 1:18 ` Eric Schulte
2010-12-02 1:36 ` Vincent Beffara
2010-12-02 9:11 ` Sébastien Vauban
2010-12-02 19:34 ` Eric Schulte
2010-12-02 20:10 ` Sébastien Vauban
2010-12-03 10:27 ` Vincent Beffara
2010-12-03 11:27 ` Sébastien Vauban
2010-12-03 14:30 ` Eric Schulte
2010-12-03 15:43 ` Vincent Beffara
2010-12-05 15:30 ` Eric Schulte
2010-12-06 9:42 ` Dan Davison [this message]
2010-12-06 11:53 ` Eric S Fraga
2010-12-06 16:42 ` Thomas S. Dye
2010-12-06 18:07 ` Achim Gratz
2010-12-06 18:40 ` Thomas S. Dye
2010-12-06 18:23 ` Dan Davison
2010-12-02 14:29 ` Eric Schulte
2010-12-02 16:12 ` Vincent Beffara
2010-12-02 18:23 ` Dan Davison
2010-12-02 19:36 ` Eric Schulte
2010-12-02 20:05 ` Sébastien Vauban
2010-12-02 16:09 ` Sébastien Vauban
2010-12-02 16:44 ` Vincent Beffara
2010-12-03 14:56 ` Christopher Allan Webber
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d3pfjkyl.fsf@gmail.com \
--to=dandavison7@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
--cc=vbeffara@ens-lyon.fr \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.