tyler.smith at mail.mcgill.ca
Mon Jun 15 19:35:07 CEST 2009
Rodney Sparapani <rsparapa at mcw.edu> writes:
> tyler wrote:
>> tyler:ess-svn-> diff scratch/ess-trns.el lisp/ess-trns.el 34a35
>> < ;;(ess-transcript-send-command) ;; This doesn't work properly
>> < ;; custom code follows:
>> < (let* ((proc (or ess-local-process-name
>> < (ess-request-a-process "Evaluate into which process? " t)))
>> < (ess-buf (get-ess-buffer proc)))
>> < (setq ess-local-process-name proc)
>> < (if (get-buffer-window ess-buf) nil
>> < (display-buffer ess-buf t))
>> < (let ((input (inferior-ess-get-old-input)))
>> < (save-excursion
>> < (set-buffer ess-buf)
>> < (goto-char (point-max))
>> < (ess-eval-linewise input nil nil nil 1)))) ;; end of custom code
> I'm just trying to understand your changes. So, are you saying
> that what you have written is just a replacement for the code
> that went into ess-transcript-send-command? Or is this a
> special case where that function is not appropriate?
I think this is a special case where ess-transcript-send-command isn't
appropriate. ess-transcript-send-command calls (ess-eval-linewise
input), when what I think is needed in the context of ess-t-s-c-and-move
is (ess-eval-linewise input nil nil nil 1).
ess-t-s-c needs an argument so the calling function can
specify whether or not the wait-for-prompt argument is set in the call
as I have done above, the necessary code can be inserted directly
into ess-t-s-c-and-move, so that the original ess-t-s-c isn't used
Another possibility is that ess-t-s-c could be modified so that the
default behaviour was to wait-for-prompt. I guess that would probably
break something else, or it would already be the default.
Hope that's clearer.
There is something fascinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of fact.
More information about the ESS-help