emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jacek Generowicz <jacek.generowicz@cern.ch>
To: emacs-orgmode@gnu.org
Subject: Re: Tangling without clutter?
Date: Thu, 15 Mar 2012 09:42:26 +0100	[thread overview]
Message-ID: <4f77ebe4-90ed-4a0d-a1d4-465dcbe198d7@CERNFE22.cern.ch> (raw)
In-Reply-To: <20120315062547.GA28824@kenny.fritz.box>

At Thu, 15 Mar 2012 07:25:47 +0100,
Viktor Rosenfeld wrote:
> 
> Hi Jos'h,
> 
> have you looked at the :session header argument? I use it to define
> environment variables in bash that are used in later code blocks.
> 
> Something like this:
> 
> #+BEGIN_SRC sh :session foo
> export W="world."
> #+END_SRC
> 
> #+RESULTS:
> 
> #+BEGIN_SRC sh :session foo
> echo Hello $W
> #+END_SRC
> 
> If these code blocks are executed in order, the latter returns "Hello
> world."

Which is exactly how I was planning to use org babel to prepare a lot
of Python-based teaching material. Unfortunately ...

> Not sure though, how it interacts with Python.

... it interacts with Python in a less than ideal way. In effect, it
pretends you typed the code in the Python source block, into Python's
standard interactive shell. This leads to problems: Imagine that you
want to demonstrate how to write a simple class in Python, and that
you wish to follow Python's style guide, which states that "Method
definitions inside a class are separated by a single blank line."

So you present this example code

#+begin_src python :session :results output
class Foo:

    def __init__(self, state):
        self.state = state

    def get(self):
        return self.state
#+end_src

in the hope of writing some explanatory notes about it, before
demonstrating its use

#+begin_src python :session :results output
f = Foo('frustrated')
print f.get()
#+end_src

Unfortunately, the plan is foiled because the class definiton in the
first block fails to execute properly. This happens because Python's
standard interactive shell (in contrast to Python's non interactive
mode) understands blank lines to close all currently open blocks. This
results in the =class Foo:= block being closed before any of its
components have been defined, at which point the whole thing goes
pear-shaped.

Currently there are two things you can do to get around this problem.

1. Remove any blank lines which are inside any block in any of your
   code (resulting in very ugly and heterodox formatting of your
   Python code: not the sort of thing you want to be doing in
   tutorials, lectures, documentation, etc.).

2. Hunt down all blank lines which are inside a block, and add enough
   whitespace to match the indentation of the next non-whitespace line
   in that block (very tedious and very fragile).


Last week I had a short exchange about this, on list, with Eric
Schulte, and seem to have persuaded him that the current state of
affairs is not the desired one.

I am planning to have a look at how the situation can be improved with
the aim of providing a patch, but

1. I have zero time to devote to this in the next few weeks.

2. I have never tinkered with babel's internals before, so I cannot
   guarantee success, or quality of output.


In the meantime, I have *slightly* changed my position, since the
exchange with Eric. Last week I claimed that what the session mode
should do is, essentially, emulate Emacs' python-mode's C-c C-c
(execute the code block in the context of the session without choking
on blank lines, and without echoing any of the code itself). I stand
by this being the desired primary behaviour, but I do admit that an
alternative valid (though less important) use case would be to have
the code in the src block be 'typed' into a standard interactive
session, and have the whole session (prompt, input, output) be
produced as the result. (IIRC, this currently doesn't work properly
either: the prompts and the inputs are out of sync, and you get a
horrible mess.)

      reply	other threads:[~2012-03-15  8:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14 17:34 Tangling without clutter? Jos'h Fuller
2012-03-14 18:22 ` Thomas S. Dye
2012-03-14 18:39   ` Jos'h Fuller
2012-03-14 19:13     ` Eric Schulte
2012-03-14 19:35       ` Jos'h Fuller
2012-03-14 18:34         ` Eric Schulte
2012-03-14 22:08           ` Jos'h Fuller
2012-03-14 20:52             ` Eric Schulte
2012-03-15  6:25         ` Viktor Rosenfeld
2012-03-15  8:42           ` Jacek Generowicz [this message]

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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f77ebe4-90ed-4a0d-a1d4-465dcbe198d7@CERNFE22.cern.ch \
    --to=jacek.generowicz@cern.ch \
    --cc=emacs-orgmode@gnu.org \
    /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 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).