org babel, ess, R

org babel, ess, R

[Vikas Rawal]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

When I press C-c' in an R code block to open an edit buffer with ess, on my
computer, it splits the screen into two side-by-side windows, with the new
window on the right showing the edit buffer, and the window on the left
showing the original file.

I would like to change this behaviour in two ways.

1. I would like the window that continues to show the original file to
instead show the R session in which lines from the edit buffer can be
evaluated. I can manually change the buffer in this window to show me the R
session but I was wondering if this can be the default behaviour.

2. Split the screen horizontally rather than vertically, so that the new
window (with edit buffer) is on the top and the second window is below. I
could live with the edit buffer being at the bottom also but would
certainly prefer seeing it above so that I have the R session in the window
below to which I send the evaluated lines one by one.

Does anyone know if it may already be possible to achieve this? Or am I
making a feature request?

Vikas

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

Re: org babel, ess, R

[Vikas Rawal]

> 
> When I press C-c' in an R code block to open an edit buffer with ess, on my computer, it splits the screen into two side-by-side windows, with the new window on the right showing the edit buffer, and the window on the left showing the original file.
> 
> I would like to change this behaviour in two ways.
> 
> 1. I would like the window that continues to show the original file to instead show the R session in which lines from the edit buffer can be evaluated. I can manually change the buffer in this window to show me the R session but I was wondering if this can be the default behaviour.
> 
> 2. Split the screen horizontally rather than vertically, so that the new window (with edit buffer) is on the top and the second window is below. I could live with the edit buffer being at the bottom also but would certainly prefer seeing it above so that I have the R session in the window below to which I send the evaluated lines one by one.
> 

I can change the direction of split by adjusting split-width-threshold

So, item 2 is more or less resolved (the edit buffer is at the bottom, but that is okay).

Vikas

Re: org babel, ess, R

[Nicolas Goaziou]

Hello,

Vikas Rawal <vikaslists@agrarianresearch.org> writes:

> When I press C-c' in an R code block to open an edit buffer with ess, on my
> computer, it splits the screen into two side-by-side windows, with the new
> window on the right showing the edit buffer, and the window on the left
> showing the original file.
>
> I would like to change this behaviour in two ways.
>
> 1. I would like the window that continues to show the original file to
> instead show the R session in which lines from the edit buffer can be
> evaluated. I can manually change the buffer in this window to show me the R
> session but I was wondering if this can be the default behaviour.

I fail to see how this could be a default behaviour since this is very
specific to R source blocks.

I suggest to implement your own `org-edit-special' wrapper, and bind it
to C-c ' (or advise the function).

Regards,

-- 
Nicolas Goaziou

Re: org babel, ess, R

[Vikas Rawal]

> 
>> When I press C-c' in an R code block to open an edit buffer with ess, on my
>> computer, it splits the screen into two side-by-side windows, with the new
>> window on the right showing the edit buffer, and the window on the left
>> showing the original file.
>> 
>> I would like to change this behaviour in two ways.
>> 
>> 1. I would like the window that continues to show the original file to
>> instead show the R session in which lines from the edit buffer can be
>> evaluated. I can manually change the buffer in this window to show me the R
>> session but I was wondering if this can be the default behaviour.
> 
> I fail to see how this could be a default behaviour since this is very
> specific to R source blocks.
> 

Isn’t is what most users need while editing the code block? The possibility of evaluating the code to test and see what happens? At present, one window shows the original buffer, which is, at least in my case, not needed while I am editing the code.

Is this an R specific need? Do people working with other languages not need this?


> I suggest to implement your own `org-edit-special' wrapper, and bind it
> to C-c ' (or advise the function).
> 


Thanks for the pointer. Let me look at this.

Thanks and best wishes,

Vikas

Re: org babel, ess, R

[Nicolas Goaziou]

Hello,

Vikas Rawal <vikaslists@agrarianresearch.org> writes:

> Isn’t is what most users need while editing the code block? The
> possibility of evaluating the code to test and see what happens? 


Many languages do not support sessions. So, the only possibility to
evaluate the code is to evaluate the code block in the source buffer.

Regards,

-- 
Nicolas Goaziou

Re: org babel, ess, R

[Vikas Rawal]

> 
> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
> 
>> Isn’t is what most users need while editing the code block? The
>> possibility of evaluating the code to test and see what happens? 
> 
> 
> Many languages do not support sessions. So, the only possibility to
> evaluate the code is to evaluate the code block in the source buffer.
> 

Yes, what I am talking about is relevant only when a session is defined. What I would like is that if in a file the session is defined, C-c’ creates
a window configuration that shows the edit buffer and the session. In other cases, the two windows could show the edit buffer and the original org buffer.


Vikas

Re: org babel, ess, R

[Andreas Kiermeier]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

Hi Vikas,
for what it's worth, I usually run two windows (in the same frame),
side-by-side, with emacs maximised.
On the left I have my org file and on the right I have an R session, which
I start immediately after I open my org file.
When I use C-c ' on an R source block, the org buffer (on the left) is
replaced by by the source code edit buffer - leaving the R-session on the
right untouched.
That way I can either evaluate a whole code block (from org using C-c C-c)
or go through the source code line-by-line (using ESS).
Seems like that's what you want to do, too.
Anyway, just my two cents worth, in case it helps.
Cheers,
AK

On 3 July 2017 at 09:47, Vikas Rawal <vikaslists@agrarianresearch.org>
wrote:

> >
> > Vikas Rawal <vikaslists@agrarianresearch.org> writes:
> >
> >> Isn’t is what most users need while editing the code block? The
> >> possibility of evaluating the code to test and see what happens?
> >
> >
> > Many languages do not support sessions. So, the only possibility to
> > evaluate the code is to evaluate the code block in the source buffer.
> >
>
> Yes, what I am talking about is relevant only when a session is defined.
> What I would like is that if in a file the session is defined, C-c’ creates
> a window configuration that shows the edit buffer and the session. In
> other cases, the two windows could show the edit buffer and the original
> org buffer.
>
>
> Vikas
>

[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

Re: org babel, ess, R

[Vikas Rawal]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

> 
> for what it's worth, I usually run two windows (in the same frame), side-by-side, with emacs maximised.
> On the left I have my org file and on the right I have an R session, which I start immediately after I open my org file.
> When I use C-c ' on an R source block, the org buffer (on the left) is replaced by by the source code edit buffer - leaving the R-session on the right untouched.
> That way I can either evaluate a whole code block (from org using C-c C-c) or go through the source code line-by-line (using ESS).
> Seems like that's what you want to do, too.
> Anyway, just my two cents worth, in case it helps.

Thanks Andreas. I am perhaps being to finicky. The problem with your approach is that you would end up permanently losing screen space for the R session. I don’t want the R session obstructing my writing when I am not working on code blocks. Ideally, the R session should appear only when I am editing the code blocks in an edit buffer.

Vikas


[-- Attachment #2: Type: text/html, Size: 1919 bytes --]

Re: org babel, ess, R

[Andreas Kiermeier]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

>
> Thanks Andreas. I am perhaps being to finicky. The problem with your
> approach is that you would end up permanently losing screen space for the R
> session. I don’t want the R session obstructing my writing when I am not
> working on code blocks. Ideally, the R session should appear only when I am
> editing the code blocks in an edit buffer.
>
> Vikas
>
> ​Fair enough. I guess it comes down to personal preference.​
If I have emacs maximised, I "need" to split the frame into two windows -
otherwise a single window is too wide (and I don't have a wide screen
monitor).
Because I use this set up for running data analyses and writing reports, it
has the benefit that I can refer to output and calculations at any time.
But, each to their own.
Cheers,
AK

[-- Attachment #2: Type: text/html, Size: 1683 bytes --]

Re: org babel, ess, R

[John Hendy]

On Sun, Jul 2, 2017 at 7:17 PM, Vikas Rawal
<vikaslists@agrarianresearch.org> wrote:
>>
>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>
>>> Isn’t is what most users need while editing the code block? The
>>> possibility of evaluating the code to test and see what happens?
>>
>>
>> Many languages do not support sessions. So, the only possibility to
>> evaluate the code is to evaluate the code block in the source buffer.
>>
>
> Yes, what I am talking about is relevant only when a session is defined. What I would like is that if in a file the session is defined, C-c’ creates
> a window configuration that shows the edit buffer and the session. In other cases, the two windows could show the edit buffer and the original org buffer.

As a frequent R user, I completely relate to this. As soon as one
evaluates code in the session buffer (C-c ') with C-RET, this is the
setup you get.

I'd add to your wish that upon first visiting a file, if I go into
edit mode, 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. Perhaps
out of habit, I tend to use :session r for every block that needs to
share results. I'll make some progress, close shop for the day, and to
continue where I left off I need to be sure to C-c C-c something the
next time rather than jumping right to editing. If I forget, end up
with two buffers and I get asked where I want to evaluate every
subsequent bit of code.

Anyway, it's easy enough to run one line with C-RET once editing and
get the session buffer, but just getting it right away is also what I
would prefer.

For other languages, even though one can't evaluate in the edit
buffer, I still use this view more frequently because I get
auto-indenting vs. none (e.g. with python).


John

>
>
> Vikas

Re: org babel, ess, R

[Vikas Rawal]

> On 04-Jul-2017, at 1:22 AM, John Hendy <jw.hendy@gmail.com> wrote:
> 
> On Sun, Jul 2, 2017 at 7:17 PM, Vikas Rawal
> <vikaslists@agrarianresearch.org> wrote:
>>> 
>>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>> 
>>>> Isn’t is what most users need while editing the code block? The
>>>> possibility of evaluating the code to test and see what happens?
>>> 
>>> 
>>> Many languages do not support sessions. So, the only possibility to
>>> evaluate the code is to evaluate the code block in the source buffer.
>>> 
>> 
>> Yes, what I am talking about is relevant only when a session is defined. What I would like is that if in a file the session is defined, C-c’ creates
>> a window configuration that shows the edit buffer and the session. In other cases, the two windows could show the edit buffer and the original org buffer.
> 
> As a frequent R user, I completely relate to this. As soon as one
> evaluates code in the session buffer (C-c ') with C-RET, this is the
> setup you get.
> 

Oh! C-RET: I didn’t know this. And this itself is a big help. It is so much easier than having to change the buffer manually!

> I'd add to your wish that upon first visiting a file, if I go into
> edit mode, 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;

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,

This should surely be fixed.
> 
> Anyway, it's easy enough to run one line with C-RET once editing and
> get the session buffer, but just getting it right away is also what I
> would prefer.
> 

I agree and echo.

Thanks a ton for C-RET :)

Vikas

Re: org babel, ess, R

[Charles C. Berry]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

On Tue, 4 Jul 2017, Vikas Rawal wrote:

>
>> On 04-Jul-2017, at 1:22 AM, John Hendy <jw.hendy@gmail.com> wrote:
>>
>> On Sun, Jul 2, 2017 at 7:17 PM, Vikas Rawal
>> <vikaslists@agrarianresearch.org> wrote:
>>>>
>>>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>>>
>>>>> Isn’t is what most users need while editing the code block? The
>>>>> possibility of evaluating the code to test and see what happens?

Often, but not always.  And it would be seriously annoying to have the 
session buffer pop up every time I wanted to browse the code in a src 
block while simultaneously viewing the results of a previous invocation 
in the org buffer.

As noted by others C-RET (or C-c C-n) on an empty line will make the 
session buffer visible.

So will C-c C-z C-c C-z if you are in an ESS[S] mode buffer (and it will 
do that without trying to eval anything).

There are any number of possibilities for customizing =org-edit-src-code= 
to your liking. For example, with this code C-c M-' will display the edit 
buffer and the session buffer as desired by Vikas:

#+BEGIN_SRC emacs-lisp
   (defun my-babel-edit-src (&optional code edit-buffer)
     (interactive)
     (org-edit-src-code code edit-buffer)
      (when (string= mode-name "ESS[S]")
        (let ((cb (current-buffer)))
 	 (ess-switch-to-ESS t)
 	 (switch-to-buffer-other-window cb))))
   (define-key org-mode-map (kbd "\C-c\M-'") 'my-babel-edit-src)
#+END_SRC

There are loads of possibilities. Just hack away at that function to add 
stops and whistles.

Personally, I find that the code in this thread:

From: Andrew Kirkpatrick <ubermonk@gmail.com>
Subject: Jumping between source blocks in a file
Archived-At: <http://permalink.gmane.org/gmane.emacs.orgmode/103130>

has done a lot to ease my browsing and manipulation of src blocks even 
though it displays the org buffer along with the edit buffer --- requiring 
me to key in C-c C-z C-c C-z to get the process buffer back in view.  I 
suppose I could replace =org-edit-src-code= at the end of Andrew 
Kirkpatrick's =my-babel-src-jump= with =my-babel-src-code= to fix that. 
Maybe tomorrow...

Best,

Chuck

Re: org babel, ess, R

[Vikas Rawal]

>>>>>> possibility of evaluating the code to test and see what happens?
> 
> Often, but not always.  And it would be seriously annoying to have the session buffer pop up every time I wanted to browse the code in a src block while simultaneously viewing the results of a previous invocation in the org buffer.
> 
> As noted by others C-RET (or C-c C-n) on an empty line will make the session buffer visible.
> 
> So will C-c C-z C-c C-z if you are in an ESS[S] mode buffer (and it will do that without trying to eval anything).

This is neat. Solves my problem.

Thanks.

Vikas

Re: org babel, ess, R

[Nicolas Goaziou]

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?

Regards,

-- 
Nicolas Goaziou

Re: org babel, ess, R

[John Hendy]

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."

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

Re: org babel, ess, R

[Charles C. Berry]

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

Re: org babel, ess, R

[Vikas Rawal]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

>> 
>> "... 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’.

Indeed this does what I was originally looking for. How does one exit from this neatly? What is the equivalent of org-edit-src-exit to use with this? Using org-edit-src-exit after org-babel-switch-to-session-with-code does not close the session window.

> 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.
> 

Yes, that makes sense.

Thanks,

Vikas



[-- Attachment #2: Type: text/html, Size: 5225 bytes --]

Re: org babel, ess, R

[Charles C. Berry]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

On Wed, 5 Jul 2017, Vikas Rawal wrote:

>>>
>>> "... 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’.
>
> Indeed this does what I was originally looking for. How does one exit 
> from this neatly? What is the equivalent of org-edit-src-exit to use 
> with this? Using org-edit-src-exit after 
> org-babel-switch-to-session-with-code does not close the session window.
>

It doesn't do that now, but see below.

>> 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.
>>
>
> Yes, that makes sense.


OTOH, maybe a call to `org-babel-switch-to-session-with-code' could 
replace the `(switch-to-buffer ...)' in `org-edit-special' so C-u C-c ' 
would display the process buffer (as it does now) and also the edit buffer 
and start a new process if necessary.

But there are a few things to fix. `org-babel-switch-to-session-with-code' 
needs to set `org-src--saved-temp-window-config' after the call to 
'org-edit-src-code' so `org-edit-src-exit' can restore the window setup.
Also, it might as well use 'info' which `org-edit-special' obtains for src 
blocks when ARG is set.


Chuck

Re: org babel, ess, R

[Nicolas Goaziou]

Hello,

John Hendy <jw.hendy@gmail.com> writes:

> 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,

Thank you for the explaination.

Note that C-RET is not an Org thing, but defined by ESS mode. It doesn't
know anything about block headers.

Would it be possible to modify `ess-gen-proc-buffer-name-function' so
that it extracts the buffer name from the :session parameter?


Regards,

-- 
Nicolas Goaziou                                                0x80A93738