From: "Thomas S. Dye" <tsd@tsdye.com>
To: Dan Davison <dandavison7@gmail.com>
Cc: Vincent Beffara <vbeffara@ens-lyon.fr>, emacs-orgmode@gnu.org
Subject: Re: Re: Babel, Python and UTF-8
Date: Mon, 6 Dec 2010 06:42:55 -1000 [thread overview]
Message-ID: <9CDC3D4C-6C60-49C7-B7AB-205511BFC8C1@tsdye.com> (raw)
In-Reply-To: <87d3pfjkyl.fsf@gmail.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
next prev parent reply other threads:[~2010-12-06 16: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
2010-12-06 11:53 ` Eric S Fraga
2010-12-06 16:42 ` Thomas S. Dye [this message]
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=9CDC3D4C-6C60-49C7-B7AB-205511BFC8C1@tsdye.com \
--to=tsd@tsdye.com \
--cc=dandavison7@gmail.com \
--cc=emacs-orgmode@gnu.org \
--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.