Behavior of C-c C-n

Stephen Eglen stephen at
Tue May 18 16:28:03 CEST 2004

To follow up on my previous email, I've taken a look at this code and
think that the following patch to ess-inf.el should fix things. 

At least this is my understanding of the bug, based also on earlier
helpful reports by Robin Hankin when using `l' to send lines from help

When sending lines of code from R using C-c C-n, if the cursor in the
*R* buffer is already at the end of the buffer, the output from
sending the command will be seen.  If however before sending a line of
code to R, you move the cursor in *R* say to the start of the *R*
buffer, the cursor will stay there after sending the line.

If that describes the new buggy behaviour, then this patch should fix
it, irrespective of the value of inferior-ess-own-frame.  In this
patch, after sending a line using C-c C-n, the cursor in the *R*
buffer is put at the end of the buffer.

*** /tmp/ess-inf.el.~5.88~	Tue May 18 15:22:36 2004
--- /tmp/ess-inf.el	Tue May 18 15:22:36 2004
*** 944,951 ****
  		 (not (looking-at inferior-ess-prompt))))))
      (goto-char (marker-position (process-mark sprocess)))
      (if eob
! 	;; SJE: not sure about (goto-char (point-max)) removed here.
! 	(ess-show-buffer (buffer-name sbuffer) nil))
      (set-buffer cbuffer)
--- 944,954 ----
  		 (not (looking-at inferior-ess-prompt))))))
      (goto-char (marker-position (process-mark sprocess)))
      (if eob
! 	(progn
! 	  (save-excursion
! 	    (set-buffer sbuffer)
! 	    (goto-char (point-max)))
! 	  (ess-show-buffer (buffer-name sbuffer) nil)))
      (set-buffer cbuffer)
If you can't get the patch to work, grab a temporary version of
ess-inf.el from:

Thanks again for the feedback.


Stephen Eglen writes:
 > Patrick Connolly writes:
 >  > On Mon, 17-May-2004 at 04:25PM -0400, Martin Henry H. Stevens wrote:
 >  > 
 >  > |> Mac OS X 10.3.3
 >  > |> GNU Emacs
 >  > |> ESS 5.2.0
 >  > |> R 2.0.0
 >  > |> 
 >  > |> When I use C-c C-n to submit a line of R code from my source code
 >  > |> to the R process (and step to the next line), I would like my R
 >  > |> process window to keep up with the current submitted
 >  > |> code. Currently, it does not, yet I know that in other
 >  > |> implementations, this keeping-up by the R process has
 >  > |> occurred. What is "normal" and how might I change this behavior?
 >  > 
 >  > It's the same with 
 >  > 
 >  > GNU Emacs 21.2.1
 >  > ESS 5.2.0
 >  > R 1.9.0
 >  > platform i686-pc-linux-gnu
 >  > 
 >  > With previous versions of ESS, it did what you and I prefer.  I
 >  > previously used 5.1.23 which did work "properly".  I tried the
 >  > ess-5.2.0rc3, for a short time, and it wasn't a problem with it
 >  > either.  If the change is intentional, I didn't notice its being
 >  > mentioned (but I'm not all that observant).
 > I think you may have found something that I introduced inadvertanly
 > when updating ESS to handle diplay of the *R* buffer in the correct
 > window (or frame, if inferior-ess-own-frame is set to t).  If you get
 > time, please can you send (to me or to ess-help) a test case of
 > exactly what you do to see the error, and I will test it.  Also, what
 > is your value of inferior-ess-own-frame?
 > For lisp readers, the problem I think is at the end of
 > the defun of ess-eval-linewise in ess-inf.el; it has the following:
 >     (if eob
 > 	;; SJE: not sure about (goto-char (point-max)) removed here.
 > 	(ess-show-buffer (buffer-name sbuffer) nil))
 >     (set-buffer cbuffer)
 >     ))
 > I obviously comment out the (goto-char (point-max)) for a reason, but
 > it escapes me for now.  
 > Thanks, Stephen
 > ______________________________________________
 > ESS-help at mailing list

More information about the ESS-help mailing list