Aloha Herb, I think a note to that effect belongs here: http://orgmode.org/manual/session.html#session
Perhaps the behavior related to session persistence could be described there, as well. Examples are probably best left to the language-specific documentation, such as it is, at http://orgmode.org/worg/org-contrib/babel/languages/ Note that there is no language-specific documentation for Python yet. Is it the case that the Ruby and Perl interpreters won't run code that does run in non-session mode? All the best, Tom Herbert Sitz <hs...@nwlink.com> writes: > Thomas S. Dye <tsd <at> tsdye.com> writes: >> >> Aloha Herbert, >> >> I think you're right about the potential to improve the documentation. >> That's an on-going process. Could you suggest some specific changes? >> >> All the best, >> Tom > > Tom -- > > I would suggest just adding specific warnings that session-based evaluation > may > throw syntax errors with valid code. > > Here's what Org manual says regarding :session evaluation with :results > output': > > "The code is passed to the interpreter running as an interactive Emacs > inferior > process. The result returned is the concaOrg tenation of the sequence of > (text) > output from the interactive interpreter. Notice that this is not necessarily > the > same as what would be sent to STDOUT if the same code were passed to a > non-interactive interpreter running as an external process. . . ." > [http://orgmode.org/manual/Results-of-evaluation.html#Results-of-evaluation] > > All that needs to be added is a warning: > > "IMPORTANT: Note that Org provides only a thin wrapper around a language's > interactive shell, so valid code that executes properly in non-session mode > may > fail in :session mode. This is because Org feeds the lines in a :session > block > to the interactive interpreter exactly as written. In come cases the lines > may > require special formatting in the source block to be executed properly in the > interactive shell. For example: . . . " > > I think the above issue should be moot for some of the main interpreted > languages (viz., Python, Perl, Ruby) where there are various ways to execute a > block of code non-interactively despite being in the interactive shell. (One > of > those methods is the example I gave in previous message.) In that case > identical code will run the same whether it's in an interactive-interpreter > session or not. It seems to me that switching to that approach for languages > that support it should both (1) simplify the Org Babel code, and (2) provide > Org > users with more flexibility and power. > > Also, it seems the real power of :session evaluation is to share state between > Org/Babel source code blocks, not merely to act as a kind of Org-internal > scratchpad. As a user trying to take advantage of that state-sharing power I > would generally want my Org document exports to start from fresh sessions. > That > is, I would write my :session blocks so that they depended on results of code > run in previous :session blocks, BUT I would want the first :session block to > start with a fresh session,with a known state. So on export I would > generally > want any existing named session to be closed and restarted anew for an > Org export. > > I hope that all makes sense. I should say I'm not a big Babel user, and I > could > easily be misunderstanding something. But it seems this is the way the > :session-based stuff should work, when possible. > > -- Herb > > > -- Thomas S. Dye http://www.tsdye.com