Re: org babel, ess, R

["Charles C. Berry" <ccberry@ucsd.edu>]

On Wed, 5 Jul 2017, John Hendy wrote:

> On Wed, Jul 5, 2017 at 4:22 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>> Hello,
>>
>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>
>>> C-RET seems to be picking up the custom session name if it is already
>>> there. But otherwise it generates the default *R* session there,
>>
>> Is there a bug to fix? If so, could start a new thread about it, ideally
>> with an ECM demonstrating the issue?
>
> I guess Vikas can speak for Vikas, but he was responding to my
> observation of the same:
>
> "... I'd like Org to pick up the fact that there's a :session
> argument with a custom name and use that for C-RET in the edit buffer;
> otherwise it generates the default *R* session there, but if you C-c
> C-c the block later it puts it into the custom session name."

This is what `org-babel-switch-to-session-with-code' does.  BTW, it also 
handles Vikas' original issue of displaying both the edit buffer and the 
process buffer during editing src blocks.

So you might want is to use `org-babel-switch-to-session-with-code' rather 
than `org-edit-src-code'.

I do not think I'd want to replace `org-edit-src-code' in 
`org-edit-special' with that function by default, since it forces a 
session to start and displays the process buffer which is kind of annoying 
when all I want to do is browse code in an edit buffer.  It fails with an 
error when applied to a src block with no session, so that would need to 
be handled if `o-b-s-t-session-w-code' is supplied as an option.

HTH,

Chuck

>
> Here's an ECM:
>
> #+begin_example
>
> * heading
>
> #+name: x
> #+begin_src R :session r
>
> x <- 1:10
>
> #+end_src
>
> #+name: y
> #+begin_src R :session r
>
> y <- x^2
>
> #+end_src
>
> #+end_example
>
> So, say I start working on a document for the day and enter the
> editing buffer with C-c ' on block x. I then C-RET from the edit
> buffer, which evaluates x and starts a new R session, *R*. Now I'm
> done and go on to block y, but don't need to edit. Maybe I just want
> to update a plot or other result in the document, so I C-c C-c:
>
> Error: object 'x' not found
>
> This really, really common for my work. I define a setup block
> somewhere in which I load libraries, read in thousands of lines of
> sensor code, and process things (moving averages, summary stats, etc.)
> and create my sort of "master object." From there I have sections of a
> report that subset the data, plot various things, but typically have
> them all set to :eval no by default. If I pick up work on a file, edit
> my setup code block, but only interactively because I forget I need to
> C-c C-c something first to kick off the custom session, the work was
> sort of for naught as everything is in the wrong session.
>
> In this example, I realize the error and go back to block x and C-c
> C-c after failing on block y. At that point, when I go to a block
> interactively to do C-RET again, I get this in the minibuffer.
>
> Process to load into: {r | *R* | *new* }
>
> Then I switch to *R* to quit() and end the spurious session.
>
> Really, it was a comment about how Org behaves, not necessarily a bug.
> That said, speaking for myself, I would never want a default session
> in interactive mode when I've defined one in the code heading. I'd
> love if Org could pick up on that setting, such that the first C-RET
> of the day dropped into the session named by the block I'm editing. At
> present, interactive mode appears to ignore this.
>
>
> Hope that helps clarify,
> John
>
>
>
>
>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>
>

Charles C. Berry                 Dept of Family Medicine & Public Health
cberry at ucsd edu               UC San Diego / La Jolla, CA 92093-0901
http://biostat.ucsd.edu/ccberry.htm