From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Sitz Subject: Re: org-babel -- Improper syntax error in session mode? Date: Mon, 20 Jun 2011 23:16:08 +0000 (UTC) Message-ID: 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; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:57554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYnhf-0007xs-TS for emacs-orgmode@gnu.org; Mon, 20 Jun 2011 19:16:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYnhe-00044o-Au for emacs-orgmode@gnu.org; Mon, 20 Jun 2011 19:16:23 -0400 Received: from lo.gmane.org ([80.91.229.12]:42999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYnhd-00044X-UX for emacs-orgmode@gnu.org; Mon, 20 Jun 2011 19:16:22 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QYnhc-0003No-A8 for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 01:16:20 +0200 Received: from c-24-22-131-140.hsd1.wa.comcast.net ([24.22.131.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Jun 2011 01:16:20 +0200 Received: from hsitz by c-24-22-131-140.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Jun 2011 01:16:20 +0200 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: emacs-orgmode@gnu.org On Mon, Jun 20, 2011 at 2:15 PM, Eric Schulte wrote: > > As far as I can tell the problem with the block below (missing the > space) is due to problems with the Python interpreter. It's not due to any problem with the interpreter itself, it's due to a purposeful design decision about the way the interactive shell should work. It makes good sense to require that extra line in interactive mode, given Python's reliance on carriage-returns and indents as part of its syntax, along with decision that the interactive output should be provided at the end of every "level 1" block. The blank line is the only way to end a "level 1 block without starting a second level 1 block. >> >> I hope I'm not confusing things. > > No worries, however, I maintain that it is beyond the scope of Babel's > Python interaction to address examples such as the one given above which > do not work when typed into the Python verbatim session by the user. > >> The patch does help, but doesn't address the extra-line insertion >> issue. > > Fair enough. > 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. (1b) It's not obvious to the Babel user that sessions are being processed using Python's interactive shell. Even if that is known (I know it's somewhere in the docs), 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. (If I'm first to report the issue maybe there aren't many Org users trying to use :session mode with Python, though.) (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. > 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. 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. Regards, Herb