* Re: [Dan Davison] Re: org-babel interpreter prompts
[not found] <87bpfx6i77.fsf@stats.ox.ac.uk>
@ 2010-02-10 19:12 ` Eric Schulte
0 siblings, 0 replies; only message in thread
From: Eric Schulte @ 2010-02-10 19:12 UTC (permalink / raw)
To: Dan Davison; +Cc: Org Mode
Hi Rick/Dan,
I have a suggestion below,
Dan Davison <davison@stats.ox.ac.uk> writes:
> I meant to CC this to you.
>
> From: Dan Davison <davison@stats.ox.ac.uk>
> Subject: Re: [Orgmode] org-babel interpreter prompts
> To: Rick Moynihan <rick.moynihan@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Date: Wed, 10 Feb 2010 13:44:59 -0500
>
> Rick Moynihan <rick.moynihan@gmail.com> writes:
>
>> Hi all,
>>
>> I'm wondering if it's possible to get org-babel to output the
>> interpreter prompts and sessions, as if each expression in the src
>> block had been entered into the repl... e.g. something like:
>>
>> #+begin_src ruby :output repl
>> 10 + 10
>> puts "hello world"
>> [1,2,3,4,5,6,7,8,9,10].map do |i|
>> i * i
>> end
>> #+end_src
>>
>> Yielding:
>>
>> #+results
>> : irb(main):001:0> 10 + 10
>> : => 20
>> : irb(main):002:0> puts "Hello World"
>> : Hello World
>> : => nil
>> : irb(main):003:0> [1,2,3,4,5,6,7,8,9,10].map do |i|
>> : irb(main):004:1* i * i
>> : irb(main):005:1> end
>> : => [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
>> : irb(main):006:0>
>>
>> The rational for this is that it lets you provide examples of being at
>> the prompt and write better documentation. I'd imagine that in this
>> mode, you wouldn't want the original src block to be rendered, rather
>> just the output as if it had been run interactively.
>>
>> I'd personally find this useful and would like to see this for ruby,
>> shell and clojure modes... Though it'd be nice to have it work for
>> all the other languages and modes that support a REPL or interactive
>> prompt too.
>
> Hi Rick,
>
> I believe this should be possible when using :session by altering the
> code that processes the output from the comint buffer. I had a quick
> attempt at hacking that and failed, as Eric's code in that area is quite
> sophisticated for me. (I still don't get how to debug macros.) So over
> to Eric.
>
I actually went through great length to keep from including the shell
prompts in command output. Also there is the issue of knowing when and
how much of the resulting buffer to return... Rather than add this as
org-babel functionality could I propose that you use a combination
of :session execution and a small Emacs helper function like the
following untested function?
UNTESTED
--8<---------------cut here---------------start------------->8---
(defun babel-execute-w-transcript ()
"Execute the current source-code block, and copy the activated
portion of the results buffer to the kill ring."
(interactive)
(let* ((session-buffer (cdr (assoc :session (third org-babel-get-src-block-info))))
(beginning (save-excursion (set-buffer session-buffer)
(process-mark (get-buffer-process (current-buffer)))))
ending)
(call-interactively org-babel-execute-src-block)
(save-excursion
(setq ending (process-mark (get-buffer-process (current-buffer))))
(kill-ring-save beginning ending))))
--8<---------------cut here---------------end--------------->8---
if you bind the above to a key w/`local-key-binding' then you can use it
to execute all of your source-code blocks and then paste the resulting
transcript wherever you like.
>
> Note that when not using :session, this effect may still be possible on
> a language-by-language basis. For example, with R we can control this
> with arguments to the R executable:
>
> ~> echo '4+4' | R --vanilla
>> 4+4
> [1] 8
>>
> ~> echo '4+4' | R --vanilla --slave
> [1] 8
> ~>
>
> and so a simple change to org-babel-R.el could introduce user control
> over this when using external process evaluation (a.o.t. session).
>
> I don't know whether ruby has something similar. For shell I'm also not
> sure. There's bash -x, but that's not quite the same.
>
> So perhaps we could introduce variables called something like
> org-babel-ruby-args and org-babel-R-args so that the user can specify
> these command line args to external interpreters.
>
The introduction of those variables does sound like a good idea, as does
holding the names of the executable commands in user-customizable
variables.
Best -- Eric
>
> Dan
> ----------
^ permalink raw reply [flat|nested] only message in thread