[ESS] ESS[S] freezes until job completion?

[Martin Maechler]

>>>>> "MM" == Martin Maechler <maechler at stat.math.ethz.ch>
>>>>>     on Tue, 26 Sep 2006 08:36:49 +0200 writes:

>>>>> "RoSp" == Rodney Sparapani <rsparapa at mcw.edu>
>>>>>     on Mon, 25 Sep 2006 16:03:42 -0500 writes:

    RoSp> Thomas Widland wrote:
    >>> I have a similar problem with GNU Emacs locking up. I
    >>> often run S+ in interactive mode through ESS. Any time I
    >>> run a command, Emacs locks up completely until the
    >>> commands completes. The ^G trick gets me Emacs back and
    >>> the command still completes. However, I frequently need
    >>> to paste several S+ commands at once into ESS. If I use
    >>> the ^G trick, I get my Emacs back but only the current
    >>> S+ command completes, rather than the whole sequence of
    >>> commands.
    >>> 
    >>> These are commands that take 5-20 min. in total, for
    >>> which I'd prefer to go through ESS rather than using
    >>> batch mode or something else. Wrapping them up in a
    >>> function or putting them all on the same line with
    >>> semicolons works, but both are very cumbersome. Any
    >>> suggestions?
    >>> 

    RoSp> That's very weird.  I can confirm this behavior on
    RoSp> xemacs with the 5.3.2.  Also, another thing related to
    RoSp> the original post, if I do \C-c \C-l like David
    RoSp> suggested, the commands are never echoed to the *R*
    RoSp> buffer, nor the output!  You just stare at it until a
    RoSp> new > appears and all of the good stuff went to the
    RoSp> big bit-bucket up in the sky.  Who wants that?  I must
    RoSp> be missing something very fundamental here.

    MM> Hmm, what about the "ESS development version", i.e.
    MM> pre-5.3.3?  Does that show the same behavior?  (and is
    MM> it really different from ESS 5.3.1 ?)

I've now checked myself:
ESS 5.3.1 properly says "Load sucessfull" and so does ESS "pre-5.3.3",
but 5.3.2 remains very calm...

---> I'll release ESS 5.3.3 immediately.
Martin