Behavior of C-c C-n

[Stephen Eglen]

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