[ESS] no output in ESS until interrupt

[Vitalie Spinu]

  >> Ross Boylan <ross at biostat.ucsf.edu>
  >> on Fri, 21 Dec 2012 16:42:30 -0800 wrote:

  > Oh boy, I just realized I was having this problem on a completely different
  > system:
  > ESS 5.11, emacs 23.2.1, Debian GNU/Linux squeeze.
  > It may have been happening on Windows too, but I'm much less sure of that.

  > On 12/21/2012 3:47 PM, Vitalie Spinu wrote:
  >> >> Ross Boylan <ross at biostat.ucsf.edu>
  >> >> on Fri, 21 Dec 2012 15:32:11 -0800 wrote:
  >> 
  >> > While debugging an R function I noticed that the main *R* window did not show
  >> > any output after an error occurred, until I hit ^G.  This was true even when the
  >> > output was from the recover() function.  ESS may not have shown the output of a
  >> > regular, but slow, function either, even if there was no error.
  >> 
  >> > Are things supposed to work that way?  Anything I can do about it? I don't
  >> > recall this problem in the past, but that may be because I wasn't using
  >> > long-running functions.
  >> 
  >> This happens because, by default, ESS waits for the output before
  >> printing (we hope to lift this limitation some day).
  > I don't understand the previous sentence.  If there is no output, there is
  > nothing to print.  And my problem is that there is output (e.g., a
  > traceback)--at least in the sense that R has finished its part and wants to send
  > output--but it is not printed.  Instead, emacs is unresponsive (i.e., I can't
  > even switch to other buffers) until I hit ctl-g, at which point the output
  > appears.

That is a bug probably. If R finished his part, ESS should print output
either way. 

  > 
  >> 
  >> If your problem is in the console, then you have to set
  >> comint-process-echoes to nil in ess hook.
  > By console, do you mean the *R* buffer?  That is where the output fails to
  > appear.  On the other hand, since everything locks up, it's not just in the
  > console.

  > Hmm.. comint-process-echoes is t in that buffer.  Now I'm kind of surprised I
  > see anything.  Why does hitting ctl-g make a difference?

Because emacs wiats for a subprocess to finish, and because emacs (as
yet) is not multithreaded you have to wait. C-g unlocks the waiting
loop.

  > I set comint-process-echoes to nil (in the *R* buffer, though not the one from
  > which I sent the command, for which it was already nil), but it didn't change
  > the behavior.

This works with a recent version of ESS, there has been quite some work
done on these issues recently. Please upgrade.

    Vitalie