Re: Re: Babel, Python and UTF-8

["Thomas S. Dye" <tsd@tsdye.com>]

Hi Dan,

Emacs configuration is one of the highest barriers to entry for  
potential adopters of Org-mode, IMO.  The idea of context-sensitive  
configuration is potentially terrific.  It gets the user to work more  
quickly than would otherwise be the case.  The problem I've run into  
is that exiting a buffer doesn't change the configuration back to some  
initial, or base, state.  I'm on to the next task but still configured  
to do the last thing.

I'm not a software engineer, so this idea might be wacky, but it seems  
to me that some code to restore the user's start-up settings would be  
a useful, standard part of an Org-mode file, something like the export  
template that many (most?) org-mode files use.   I think it would be  
handy to be able to stick something simple in my Org-mode file so that  
I was confident I knew exactly how Emacs was configured while I was  
using that file.

Tom

On Dec 5, 2010, at 11:42 PM, Dan Davison wrote:

> "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
>
> _______________________________________________
> 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