* Babel, Python and UTF-8
@ 2010-12-01 23:50 Vincent Beffara
2010-12-02 1:18 ` Eric Schulte
0 siblings, 1 reply; 25+ messages in thread
From: Vincent Beffara @ 2010-12-01 23:50 UTC (permalink / raw)
To: emacs-orgmode
Hi,
I am discovering org-mode and org-babel, and wanted to try it out with
python code blocks. My use case would involve text processing, encoded
as UTF-8. Usually a python file has to contain a line to that effect,
saying sth like # -*- coding: utf-8 -*- (without which an error is
raised).
Is there a way to manage that during org-babel block evaluation ?
Thanks for your help !
/v
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
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
0 siblings, 1 reply; 25+ messages in thread
From: Eric Schulte @ 2010-12-02 1:18 UTC (permalink / raw)
To: Vincent Beffara; +Cc: emacs-orgmode
Hi Vincent,
I would suggest just trying it out first and seeing if you get an error
without such a line. Also, you could try adding the line to the
beginning of your code block.
If there is definitely a problem please reply to this thread and we
could easily add a header argument for this case, possibly named
":prefix" which could be used to specify such a code-block-prefix for
code evaluation. This header argument could then be set globally or on
the file, heading, or code block level.
Best -- Eric
Vincent Beffara <vbeffara@ens-lyon.fr> writes:
> Hi,
>
> I am discovering org-mode and org-babel, and wanted to try it out with
> python code blocks. My use case would involve text processing, encoded
> as UTF-8. Usually a python file has to contain a line to that effect,
> saying sth like # -*- coding: utf-8 -*- (without which an error is
> raised).
>
> Is there a way to manage that during org-babel block evaluation ?
>
> Thanks for your help !
>
> /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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-02 1:18 ` Eric Schulte
@ 2010-12-02 1:36 ` Vincent Beffara
2010-12-02 9:11 ` Sébastien Vauban
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Vincent Beffara @ 2010-12-02 1:36 UTC (permalink / raw)
To: emacs-orgmode
Hi,
> I would suggest just trying it out first and seeing if you get an error
> without such a line.
Well, I do, that's why I'm asking ;-)
> Also, you could try adding the line to the beginning of your code
> block.
I tried like this :
--8<---------------cut here---------------start------------->8---
#+begin_src python
# -*- coding: utf-8 -*-
s = "é"
#+end_src
--8<---------------cut here---------------end--------------->8---
The error message tells me that the error happens on line 4, hence the
coding line ends up on line 3, and python only takes it into account if
it is one of the first two ... so it almost works, but it doesn't.
> If there is definitely a problem please reply to this thread and we
> could easily add a header argument for this case, possibly named
> ":prefix" which could be used to specify such a code-block-prefix for
> code evaluation. This header argument could then be set globally or on
> the file, heading, or code block level.
That would be fantastic ! (And possibly useful in other cases as well
...)
Thanks,
/vincent
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
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 14:29 ` Eric Schulte
2010-12-02 16:09 ` Sébastien Vauban
2 siblings, 1 reply; 25+ messages in thread
From: Sébastien Vauban @ 2010-12-02 9:11 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Vincent and Eric,
Vincent Beffara wrote:
>> I would suggest just trying it out first and seeing if you get an error
>> without such a line.
>
> Well, I do, that's why I'm asking ;-)
>
>> Also, you could try adding the line to the beginning of your code
>> block.
>
> I tried like this :
>
> #+begin_src python
> # -*- coding: utf-8 -*-
> s = "é"
> #+end_src
I'm not sure to understand your problem. In fact, the problem is not about
"inserting a prefix to the block", it's about the coding system itself, I
guess.
Your "é" in your Org buffer, how is it encoded? Is your Org buffer an UTF-8
one, or a Latin-1?
In the first case, I don't see why:
- it would fail
- it would even need to be specified
In the second, you want an ISO Latin 1 block of text to be tangled or executed
as UTF-8. Is this right?
> The error message tells me that the error happens on line 4, hence the
> coding line ends up on line 3, and python only takes it into account if
> it is one of the first two ... so it almost works, but it doesn't.
>
>> If there is definitely a problem please reply to this thread and we
>> could easily add a header argument for this case, possibly named
>> ":prefix" which could be used to specify such a code-block-prefix for
>> code evaluation. This header argument could then be set globally or on
>> the file, heading, or code block level.
Isn't such a prefix already available through the "shebang" option: can't it
be multiline? Anyway, I don't think it's the problem here...
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
2010-12-02 1:36 ` Vincent Beffara
2010-12-02 9:11 ` Sébastien Vauban
@ 2010-12-02 14:29 ` Eric Schulte
2010-12-02 16:12 ` Vincent Beffara
2010-12-02 18:23 ` Dan Davison
2010-12-02 16:09 ` Sébastien Vauban
2 siblings, 2 replies; 25+ messages in thread
From: Eric Schulte @ 2010-12-02 14:29 UTC (permalink / raw)
To: Vincent Beffara; +Cc: emacs-orgmode
Hi,
I've just pushed up a new prefix header argument. This header argument
only has meaning for python code blocks (since it is tied into
evaluation each language would have to handle it separately). This is
only used during external evaluation (i.e. not when :session is
specified) and the value of the :prefix argument is prepended to the
temporary file evaluated by python.
The following demonstrate its usage:
** Python requires a utf-8 coding prefix
#+begin_src python :prefix # -*- coding: utf-8 -*- :return s
s = "é"
#+end_src
#+results:
: é
#+begin_src python :prefix # -*- coding: utf-8 -*- :results output
s = "é"
print(s)
#+end_src
#+results:
: é
Best -- Eric
Vincent Beffara <vbeffara@ens-lyon.fr> writes:
> Hi,
>
>> I would suggest just trying it out first and seeing if you get an error
>> without such a line.
>
> Well, I do, that's why I'm asking ;-)
>
>> Also, you could try adding the line to the beginning of your code
>> block.
>
> I tried like this :
>
> #+begin_src python
> # -*- coding: utf-8 -*-
> s = "é"
> #+end_src
>
> The error message tells me that the error happens on line 4, hence the
> coding line ends up on line 3, and python only takes it into account if
> it is one of the first two ... so it almost works, but it doesn't.
>
>> If there is definitely a problem please reply to this thread and we
>> could easily add a header argument for this case, possibly named
>> ":prefix" which could be used to specify such a code-block-prefix for
>> code evaluation. This header argument could then be set globally or on
>> the file, heading, or code block level.
>
> That would be fantastic ! (And possibly useful in other cases as well
> ...)
>
> Thanks,
>
> /vincent
>
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-02 1:36 ` Vincent Beffara
2010-12-02 9:11 ` Sébastien Vauban
2010-12-02 14:29 ` Eric Schulte
@ 2010-12-02 16:09 ` Sébastien Vauban
2010-12-02 16:44 ` Vincent Beffara
2 siblings, 1 reply; 25+ messages in thread
From: Sébastien Vauban @ 2010-12-02 16:09 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Vincent and Eric,
Vincent Beffara wrote:
>> I would suggest just trying it out first and seeing if you get an error
>> without such a line.
>
> Well, I do, that's why I'm asking ;-)
>
>> Also, you could try adding the line to the beginning of your code
>> block.
>
> I tried like this :
>
> #+begin_src python
> # -*- coding: utf-8 -*-
> s = "é"
> #+end_src
I'm not sure to understand your problem. In fact, the problem is not about
"inserting a prefix to the block", it's about the coding system itself, I
guess.
Your "é" in your Org buffer, how is it encoded? Is your Org buffer an UTF-8
one, or a Latin-1?
In the first case, I don't see why:
- it would fail
- it would even need to be specified
In the second, you want an ISO Latin 1 block of text to be tangled or executed
as UTF-8. Is this right?
> The error message tells me that the error happens on line 4, hence the
> coding line ends up on line 3, and python only takes it into account if
> it is one of the first two ... so it almost works, but it doesn't.
>
>> If there is definitely a problem please reply to this thread and we
>> could easily add a header argument for this case, possibly named
>> ":prefix" which could be used to specify such a code-block-prefix for
>> code evaluation. This header argument could then be set globally or on
>> the file, heading, or code block level.
Isn't such a prefix already available through the "shebang" option: can't it
be multiline? Anyway, I don't think it's the problem here...
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-02 14:29 ` Eric Schulte
@ 2010-12-02 16:12 ` Vincent Beffara
2010-12-02 18:23 ` Dan Davison
1 sibling, 0 replies; 25+ messages in thread
From: Vincent Beffara @ 2010-12-02 16:12 UTC (permalink / raw)
To: emacs-orgmode
Hi,
> I've just pushed up a new prefix header argument.
Fantastic ! It works exactly as needed. Thanks a lot !
> This header argument only has meaning for python code blocks (since it
> is tied into evaluation each language would have to handle it
> separately).
That's fine, most cases can probably be handled using something like
<<prefix>> anyway. It is just Python insisting to find the coding
instruction in the first 2 lines that causes trouble, so a specific
implementation makes sense.
Thanks again,
/v
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-02 16:09 ` Sébastien Vauban
@ 2010-12-02 16:44 ` Vincent Beffara
2010-12-03 14:56 ` Christopher Allan Webber
0 siblings, 1 reply; 25+ messages in thread
From: Vincent Beffara @ 2010-12-02 16:44 UTC (permalink / raw)
To: emacs-orgmode
>> #+begin_src python
>> # -*- coding: utf-8 -*-
>> s = "é"
>> #+end_src
>
> I'm not sure to understand your problem. In fact, the problem is not
> about "inserting a prefix to the block", it's about the coding system
> itself, I guess.
>
> Your "é" in your Org buffer, how is it encoded? Is your Org buffer an
> UTF-8 one, or a Latin-1?
Doesn't really matter, in fact ... Whenever a python file contains a
non-ascii character (utf-8 or latin-1) it insists on finding an
indication of the encoding within the file. If latin-1, it finds \xe9,
if utf-8, it finds \xc3, but in both cases it raises this:
# SyntaxError: Non-ASCII character '\xe9' in file /Users/vincent/toto.py
# on line 1, but no encoding declared; see
# http://www.python.org/peps/pep-0263.html for details
That's even if the character in question lies within a string. That
makes a lot of sense in terms of portability, but it makes on-the-fly
evaluation a bit more complicated.
> In the second, you want an ISO Latin 1 block of text to be tangled or
> executed as UTF-8. Is this right?
No, I want everything in utf-8, there is no converting to do anywhere,
just telling python that it is utf-8.
> Isn't such a prefix already available through the "shebang" option:
> can't it be multiline? Anyway, I don't think it's the problem here...
Hmm, didn't know about :shebang, but it seems to be ignored (at least
for python) because this works without a syntax error:
--8<---------------cut here---------------start------------->8---
#+begin_src python :shebang sldfkj
return 1
#+end_src
--8<---------------cut here---------------end--------------->8---
Anyway, :prefix cannot hurt I guess ...
/v
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
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
1 sibling, 1 reply; 25+ messages in thread
From: Dan Davison @ 2010-12-02 18:23 UTC (permalink / raw)
To: Eric Schulte; +Cc: Vincent Beffara, emacs-orgmode
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2893 bytes --]
"Eric Schulte" <schulte.eric@gmail.com> writes:
> Hi,
>
> I've just pushed up a new prefix header argument.
"preamble" might be a better name? or "header"? prefix makes me think of
adding a string onto the front of a string[1]; preamble and header are
used by e.g. latex to refer to prelimary lines at the top of a file. For
obscure options like this it might be OK to use a longer name
(e.g. ":header-line"), especially now we have multiline header args
with #+header.
> This header argument
> only has meaning for python code blocks
but might in the future be used by others?
Dan
[1]: accurate i know, but many people won't think of a block as a
character string.
> (since it is tied into
> evaluation each language would have to handle it separately). This is
> only used during external evaluation (i.e. not when :session is
> specified) and the value of the :prefix argument is prepended to the
> temporary file evaluated by python.
>
> The following demonstrate its usage:
>
> ** Python requires a utf-8 coding prefix
> #+begin_src python :prefix # -*- coding: utf-8 -*- :return s
> s = "é"
> #+end_src
>
> #+results:
> : é
>
> #+begin_src python :prefix # -*- coding: utf-8 -*- :results output
> s = "é"
> print(s)
> #+end_src
>
> #+results:
> : é
>
> Best -- Eric
>
> Vincent Beffara <vbeffara@ens-lyon.fr> writes:
>
>> Hi,
>>
>>> I would suggest just trying it out first and seeing if you get an error
>>> without such a line.
>>
>> Well, I do, that's why I'm asking ;-)
>>
>>> Also, you could try adding the line to the beginning of your code
>>> block.
>>
>> I tried like this :
>>
>> #+begin_src python
>> # -*- coding: utf-8 -*-
>> s = "é"
>> #+end_src
>>
>> The error message tells me that the error happens on line 4, hence the
>> coding line ends up on line 3, and python only takes it into account if
>> it is one of the first two ... so it almost works, but it doesn't.
>>
>>> If there is definitely a problem please reply to this thread and we
>>> could easily add a header argument for this case, possibly named
>>> ":prefix" which could be used to specify such a code-block-prefix for
>>> code evaluation. This header argument could then be set globally or on
>>> the file, heading, or code block level.
>>
>> That would be fantastic ! (And possibly useful in other cases as well
>> ...)
>>
>> Thanks,
>>
>> /vincent
>>
>>
>> _______________________________________________
>> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
2010-12-02 9:11 ` Sébastien Vauban
@ 2010-12-02 19:34 ` Eric Schulte
2010-12-02 20:10 ` Sébastien Vauban
0 siblings, 1 reply; 25+ messages in thread
From: Eric Schulte @ 2010-12-02 19:34 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
>
> Isn't such a prefix already available through the "shebang" option: can't it
> be multiline? Anyway, I don't think it's the problem here...
>
The :shebang header argument is only used for tangling, not during
evaluation, however if you ever needed to tangle python code blocks with
non-ASCII encodings this would be the appropriate solution.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-02 18:23 ` Dan Davison
@ 2010-12-02 19:36 ` Eric Schulte
2010-12-02 20:05 ` Sébastien Vauban
0 siblings, 1 reply; 25+ messages in thread
From: Eric Schulte @ 2010-12-02 19:36 UTC (permalink / raw)
To: Dan Davison; +Cc: Vincent Beffara, emacs-orgmode
Dan Davison <dandavison7@gmail.com> writes:
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Hi,
>>
>> I've just pushed up a new prefix header argument.
>
> "preamble" might be a better name? or "header"? prefix makes me think of
> adding a string onto the front of a string[1];
Absolutely, "prefix" was just the most obvious to me and I certainly
don't claim that makes it the most obvious choice globally :)
I would lean against "header" since we already talk about "header
arguments", but I think "preamble" is an improvement. Does anyone have
a better suggestion?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-02 19:36 ` Eric Schulte
@ 2010-12-02 20:05 ` Sébastien Vauban
0 siblings, 0 replies; 25+ messages in thread
From: Sébastien Vauban @ 2010-12-02 20:05 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Eric and Dan,
"Eric Schulte" wrote:
> Dan Davison <dandavison7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> "Eric Schulte" <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>
>>> I've just pushed up a new prefix header argument.
>>
>> "preamble" might be a better name? or "header"? prefix makes me think of
>> adding a string onto the front of a string[1];
>
> Absolutely, "prefix" was just the most obvious to me and I certainly
> don't claim that makes it the most obvious choice globally :)
>
> I would lean against "header" since we already talk about "header
> arguments", but I think "preamble" is an improvement. Does anyone have
> a better suggestion?
I second Dan's comment, and fully am in favor of preamble... Of course, then,
one might ask for postamble ;-)
What about shebang? Isn't it a preamble as well?
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-02 19:34 ` Eric Schulte
@ 2010-12-02 20:10 ` Sébastien Vauban
2010-12-03 10:27 ` Vincent Beffara
0 siblings, 1 reply; 25+ messages in thread
From: Sébastien Vauban @ 2010-12-02 20:10 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Eric,
"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Isn't such a prefix already available through the "shebang" option: can't it
>> be multiline? Anyway, I don't think it's the problem here...
>
> The :shebang header argument is only used for tangling, not during
> evaluation, however if you ever needed to tangle python code blocks with
> non-ASCII encodings this would be the appropriate solution.
Sorry, reading this after the other post...
But, does it still make sense to make that distinction:
- some sort of preamble only for tangling?
- a preamble for evaluation (and tangling)?
Why would the shebang not be inserted as well for evaluation?
Do you/we need:
- one only for eval,
- one only for tangling,
- and one for both?
Depending on that answer, I would maybe make it more explicit what's the role
of each, like:
- :eval-preamble
- :tangle-preambel
- :preamble
But I'm wondering if one sort of preamble wouldn't be enough (and be used both
for tangling and evaluating)?
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
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
0 siblings, 2 replies; 25+ messages in thread
From: Vincent Beffara @ 2010-12-03 10:27 UTC (permalink / raw)
To: emacs-orgmode
Hi,
"preamble" sounds fine (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 ;->)
>> The :shebang header argument is only used for tangling, not during
>> evaluation, however if you ever needed to tangle python code blocks with
>> non-ASCII encodings this would be the appropriate solution.
>
> Sorry, reading this after the other post...
>
> But, does it still make sense to make that distinction:
>
> - some sort of preamble only for tangling?
> - a preamble for evaluation (and tangling)?
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.
/v
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-03 10:27 ` Vincent Beffara
@ 2010-12-03 11:27 ` Sébastien Vauban
2010-12-03 14:30 ` Eric Schulte
1 sibling, 0 replies; 25+ messages in thread
From: Sébastien Vauban @ 2010-12-03 11:27 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Vincent,
Vincent Beffara wrote:
> "preamble" sounds fine (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 ;->)
If you want a bigger preamble, just use noweb expansion:
#+begin_src python :noweb yes
<<preamble>>
...
my code
...
#+end_src
and have somewhere:
#+srcname: preamble
#+begin_src python
-*- coding-system: utf-8 -*-
...
rest of my preamble
...
#+end_src
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
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
1 sibling, 1 reply; 25+ messages in thread
From: Eric Schulte @ 2010-12-03 14:30 UTC (permalink / raw)
To: Vincent Beffara; +Cc: emacs-orgmode
Hi,
Vincent Beffara <vbeffara@ens-lyon.fr> writes:
> Hi,
>
> "preamble" sounds fine
As this seems to be the general consensus I've replaced "prefix" with
"preamble" as the header argument name
> (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. e.g.
** Python requires a utf-8 coding prefix
#+source: my-preamble
#+begin_src python :return preamble
preamble = "# -*- coding: utf-8 -*-"
#+end_src
#+begin_src python :preamble (sbe my-preamble) :return s
s = "é"
#+end_src
#+results:
: é
#+begin_src python :preamble # -*- coding: utf-8 -*- :results output
s = "é"
print(s)
#+end_src
#+results:
: é
>
>>> The :shebang header argument is only used for tangling, not during
>>> evaluation, however if you ever needed to tangle python code blocks with
>>> non-ASCII encodings this would be the appropriate solution.
>>
>> Sorry, reading this after the other post...
>>
>> But, does it still make sense to make that distinction:
>>
>> - some sort of preamble only for tangling?
>> - a preamble for evaluation (and tangling)?
>
> 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.
Evaluation requires language specific support for both performing the
evaluation and collecting the result. Evaluation can (for example) be
performed using an external file or using a persistent session. Even
when using an external file the contents of the file are often very
different when tangling and exporting, e.g.
#+source: my-preamble
#+begin_src python :return preamble
preamble = "# -*- coding: utf-8 -*-"
#+end_src
tangles to the following (possibly with comments)
--8<---------------cut here---------------start------------->8---
preamble = "# -*- coding: utf-8 -*-"
--8<---------------cut here---------------end--------------->8---
and is evaluated as the following
--8<---------------cut here---------------start------------->8---
def main():
preamble = "# -*- coding: utf-8 -*-"
return preamble
open('temporary-result-collection-file', 'w').write( pprint.pformat(main()) )
--8<---------------cut here---------------end--------------->8---
Best -- Eric
>
> /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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
2010-12-02 16:44 ` Vincent Beffara
@ 2010-12-03 14:56 ` Christopher Allan Webber
0 siblings, 0 replies; 25+ messages in thread
From: Christopher Allan Webber @ 2010-12-03 14:56 UTC (permalink / raw)
To: Vincent Beffara; +Cc: emacs-orgmode
(Also worth mentioning that python 3 allows you to use actual unicode
characters inside strings in the file, not \xff chars; not sure if
org-babel needs to change its habits between python2 and python3?)
Vincent Beffara <vbeffara@ens-lyon.fr> writes:
>>> #+begin_src python
>>> # -*- coding: utf-8 -*-
>>> s = "é"
>>> #+end_src
>>
>> I'm not sure to understand your problem. In fact, the problem is not
>> about "inserting a prefix to the block", it's about the coding system
>> itself, I guess.
>>
>> Your "é" in your Org buffer, how is it encoded? Is your Org buffer an
>> UTF-8 one, or a Latin-1?
>
> Doesn't really matter, in fact ... Whenever a python file contains a
> non-ascii character (utf-8 or latin-1) it insists on finding an
> indication of the encoding within the file. If latin-1, it finds \xe9,
> if utf-8, it finds \xc3, but in both cases it raises this:
>
> # SyntaxError: Non-ASCII character '\xe9' in file /Users/vincent/toto.py
> # on line 1, but no encoding declared; see
> # http://www.python.org/peps/pep-0263.html for details
>
> That's even if the character in question lies within a string. That
> makes a lot of sense in terms of portability, but it makes on-the-fly
> evaluation a bit more complicated.
>
>> In the second, you want an ISO Latin 1 block of text to be tangled or
>> executed as UTF-8. Is this right?
>
> No, I want everything in utf-8, there is no converting to do anywhere,
> just telling python that it is utf-8.
>
>> Isn't such a prefix already available through the "shebang" option:
>> can't it be multiline? Anyway, I don't think it's the problem here...
>
> Hmm, didn't know about :shebang, but it seems to be ignored (at least
> for python) because this works without a syntax error:
>
> #+begin_src python :shebang sldfkj
> return 1
> #+end_src
>
> Anyway, :prefix cannot hurt I guess ...
>
> /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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-03 14:30 ` Eric Schulte
@ 2010-12-03 15:43 ` Vincent Beffara
2010-12-05 15:30 ` Eric Schulte
0 siblings, 1 reply; 25+ messages in thread
From: Vincent Beffara @ 2010-12-03 15:43 UTC (permalink / raw)
To: emacs-orgmode
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.
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 ?
--8<---------------cut here---------------start------------->8---
#+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
--8<---------------cut here---------------end--------------->8---
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.
>> 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.
I am just discovering all of this, sorry if I have horrible
misconceptions about the thing ...
Regards,
/v
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
2010-12-03 15:43 ` Vincent Beffara
@ 2010-12-05 15:30 ` Eric Schulte
2010-12-06 9:42 ` Dan Davison
0 siblings, 1 reply; 25+ messages in thread
From: Eric Schulte @ 2010-12-05 15:30 UTC (permalink / raw)
To: Vincent Beffara; +Cc: emacs-orgmode
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.
>
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-05 15:30 ` Eric Schulte
@ 2010-12-06 9:42 ` Dan Davison
2010-12-06 11:53 ` Eric S Fraga
2010-12-06 16:42 ` Thomas S. Dye
0 siblings, 2 replies; 25+ messages in thread
From: Dan Davison @ 2010-12-06 9:42 UTC (permalink / raw)
To: Eric Schulte; +Cc: Vincent Beffara, emacs-orgmode
"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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
2010-12-06 9:42 ` Dan Davison
@ 2010-12-06 11:53 ` Eric S Fraga
2010-12-06 16:42 ` Thomas S. Dye
1 sibling, 0 replies; 25+ messages in thread
From: Eric S Fraga @ 2010-12-06 11:53 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
Dan Davison <dandavison7@gmail.com> writes:
> 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:
This is *really* nice. Thanks!
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 23.2.1
: using Org-mode version 7.3 (release_7.3.211.g6388.dirty)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
2010-12-06 9:42 ` Dan Davison
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:23 ` Dan Davison
1 sibling, 2 replies; 25+ messages in thread
From: Thomas S. Dye @ 2010-12-06 16:42 UTC (permalink / raw)
To: Dan Davison; +Cc: Vincent Beffara, emacs-orgmode
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
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
1 sibling, 1 reply; 25+ messages in thread
From: Achim Gratz @ 2010-12-06 18:07 UTC (permalink / raw)
To: emacs-orgmode
"Thomas S. Dye" <tsd@tsdye.com> writes:
> 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.
Isn't that what buffer-local variables are for?
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Babel, Python and UTF-8
2010-12-06 16:42 ` Thomas S. Dye
2010-12-06 18:07 ` Achim Gratz
@ 2010-12-06 18:23 ` Dan Davison
1 sibling, 0 replies; 25+ messages in thread
From: Dan Davison @ 2010-12-06 18:23 UTC (permalink / raw)
To: Thomas S. Dye; +Cc: Vincent Beffara, emacs-orgmode
"Thomas S. Dye" <tsd@tsdye.com> writes:
> 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.
Hi Tom,
I think someone else suggested using buffer-local variables to address
this problem, and I think that's the correct suggestion. One of the
examples below shows how to set a buffer-local value:
[...]
> #+source: document-config
>> #+begin_src emacs-lisp
>> (set (make-local-variable 'org-edit-src-content-indentation) 0)
>> #+end_src
As it happens, for that particular setting to be useful requires a patch
that is pending review, but, in general, I think this is the way to do
what you're describing.
Dan
>>
>> #+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
>
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Re: Babel, Python and UTF-8
2010-12-06 18:07 ` Achim Gratz
@ 2010-12-06 18:40 ` Thomas S. Dye
0 siblings, 0 replies; 25+ messages in thread
From: Thomas S. Dye @ 2010-12-06 18:40 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
On Dec 6, 2010, at 8:07 AM, Achim Gratz wrote:
> "Thomas S. Dye" <tsd@tsdye.com> writes:
>> 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.
>
> Isn't that what buffer-local variables are for?
>
>
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
> http://Synth.Stromeko.net/Downloads.html#KorgSDada
>
>
Aloha Achim,
I suppose so, but AFAIK I haven't seen them in the configuration code
blocks that Dan mentioned. I might be missing something.
I experimented with buffer-local configuration variables myself a
while back, but my Lisp skills are sub-minimal and I couldn't make
them work to my satisfaction.
All the best,
Tom
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2010-12-06 18:40 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).