From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: org-babel -- Improper syntax error in session mode? Date: Mon, 20 Jun 2011 19:19:17 -0700 Message-ID: <87fwn4vsd6.fsf@gmail.com> References: <87k4chwgpa.fsf@gmail.com> <23747.1308539849@alphaville.dokosmarshall.org> <87ei2ouwxk.fsf@gmail.com> <87aadcxl05.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:47425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYqYo-0008Ux-J2 for emacs-orgmode@gnu.org; Mon, 20 Jun 2011 22:19:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYqYn-0005Zs-4i for emacs-orgmode@gnu.org; Mon, 20 Jun 2011 22:19:26 -0400 Received: from mail-pv0-f169.google.com ([74.125.83.169]:64118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYqYm-0005Zm-Ry for emacs-orgmode@gnu.org; Mon, 20 Jun 2011 22:19:25 -0400 Received: by pvc12 with SMTP id 12so1612881pvc.0 for ; Mon, 20 Jun 2011 19:19:23 -0700 (PDT) In-Reply-To: (Herbert Sitz's message of "Mon, 20 Jun 2011 23:16:08 +0000 (UTC)") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Herbert Sitz Cc: emacs-orgmode@gnu.org Perhaps I should explain my personal view of what Babel "sessions" are, I'm not saying this is *the* view, just my own. Babel sessions explicitly are thin wrappers around the interactive mode of the language in question (whatever that may be). That is why Babel happily doesn't implement sessions for all languages, the contract simply is that if a language supports interactive evaluation, Babel will try to allow access to that functionality. If the contract was rather simply "Babel provides session based evaluation", then we'd be on the hook for implementing session evaluation where it doesn't already exist and may not make sense (e.g., C, ditaa), and normalizing everywhere else as you're suggesting here. Which would in turn requires us to spell out Babel-specific semantics of session based evaluation -- something we have thus-far avoided. Some positive points *for* the "thin wrapper" approach include; 1. It is the simplest to implement - easier to implement support for new language - easier to maintain -- especially if interactive tools change - easier to reason about -- thinking about bug fixing here - works with alternate back-ends e.g., ipython 2. It is the least surprising. I'd maintain that for users familiar with using Python sessions this behavior is the easiest to quickly understand and use. As opposed to if we did something fancy (even if it was an improvement) it would be another environment for language users to have to familiarize themselves with -- they'd have both normal session rules and babel session rules I guess that's it, I'm happy to be convinced otherwise, or simply be outvoted. If you want to look at the code I'm happy to help in any way I can, my previous patch would probably be a good place to start. Just be careful, if you get too comfortable with Emacs Lisp you might find it hard to go back to working with VM's extension language. :) a few more scattered comments below... Herbert Sitz writes: [...] > > Maybe adding the extra lines is beyond Babel's scope, strictly speaking. I can > think of some good reasons for doing it though: > > (1a) Babel is not an interactive shell. > Exactly, it is a window to a language's interactive run-time as defined by the language's tools. > > (1b) It's not obvious to the Babel user that sessions are being processed using > Python's interactive shell. I'd disagree, to my mind this is the simplest explanation of session evaluation. > Even if that is known (I know it's somewhere in the docs), Perhaps the documentation should be tweaked to make this point more clear. > it's not clear to a user why Babel would require a user to insert the > extra lines (and, it turns out, _avoid_ blank lines in other cases), > which make sense in interactive environment but not within Babel's > non-interactive environment. Even if this particular idiosyncrasy is > documented somewhere it's going to cause confusion for users who skim > the docs and just expect regular Python code to work without problems. But any *other* behavior would be surprising to users who are familiar with using Python's interactive shell, and think of code blocks as simply a place to store transcripts of interactive sessions they may want to dump back into the session at some point in the future. > > (If I'm first to report the issue maybe there aren't many Org users > trying to use :session mode with Python, though.) > or (if they are regular Python users) they didn't find this behavior to be surprising. > > (2) Isn't the blank-line issue an easy fix? I think it requires just these two > simple changes to source block before submitting to python shell: (a) Regex > search replace to add a blank line before any "unindented" line that is preceded > by an indented line (actually it may work fine to just put blank line before > _any_ "unindented" textline in the source-block); and (b) deletion of all blank > lines in the source-block that are followed by "indented" text on next line. > I agree, it shouldn't be an overly difficult fix, but I'm worried about precedent. This gives me a distinct "foot in the door" feeling, and it breaks the /thin wrapper/ contract I spelled out above. > > >> Does it work for other "normal" Python interactive code blocks? Have >> you noticed any places where the previous version worked but the new >> version doesn't? If it seems safe then I would like to apply it. > > I think the start with a stray blank line before what should be the > actual output. Otherwise It does seem to be working well with the few more > complicated things I've created to throw at it. > Great, thanks. I appreciate you testing this out. I've just applied the patch since, regardless of the outcome of this thread I think we're all agreed that the patch is better than the current behavior. > > I'm not really a big Python user, was just doing some testing in my > vim-Org-clone with Python when I noticed the problem. If you end up not > addressing the line-insertion issue I may put it on my todo-list for my first > real adventure in learning elisp. > Cool, I'm happy to help, either with your digging into elisp, or by providing Babel information/opinions for the VM clone. It's an incredible undertaking to re-implement something as massive as Org-mode in a new environment and I'm excited to hear you're getting up to the more esoteric features like Babel. Best -- Eric > > Regards, > > Herb > > > > -- Eric Schulte http://cs.unm.edu/~eschulte/