Re: tramp (2.2.3-24.1); Using tramp to run ess-remote session. Submitting more than one line of code at a time, causes emacs to wait indefinitely.

[Michael Albinus]

Tobias Muhlhofer <address@hidden> writes:

[Still Cc'ing address@hidden For the archives.]

> Michael:

Hi Tobias,

>> In order to reduce side effects, run your tests with
>>
>> emacs -Q -L /usr/share/emacs/site-lisp/ess -l ess-site

I'm using now 

# emacs24 -Q -L /usr/share/emacs24/site-lisp/ess -l ess-site

But this shouldn't make a difference. It is just to distinguish from the
Emacs development version, which is installed on my machine as well.

> Here's how I tested M-x R for remote machines.
>
> 1) Started emacs with 'emacs -Q -L /usr/share/emacs/site-lisp/ess -l
> ess-site', as specified.
> 2) In the *scratch* buffer that comes up, did M-x R, and selected a
> tramp path as the starting directory (/<username>@<server>:/<path>).
> 3) I was asked for my password in the minibuffer.
> 4) Emacs hung until I did C-g.

I have applied exactly the same scenario as you did. No problem at
all. Here are the versions I am using:

C-h v emacs-version -> "24.2.1"
C-h v tramp-version -> "2.2.3-24.1"
C-h v ess-version -> "12.09-2"

Note, that Emacs 24.1 and 24.2 are almost identical (there was just a
security fix in 24.2).

Furthermore, after the "M-x R" command returned, I have opened my local
123.R file, I have selected a region, and I have applied "C-c M-r". It
worked smoothly. As you have mentioned, "M-x ess-remote" was not
necessary. ESS has detected the running R process correctly.

> The tramp buffer was EMPTY (I used tramp verbose at 6).

The Tramp buffer is not of interest. There must be a Tramp debug buffer
"*debug tramp/scpc tmuhlhof...*", which I would like to see.

> Again, let me know if I should bring this up with the ESS folks.

Not yet. Since it does work for me out of the box, there is a chance
that the problem is related to your setup, which we should be able to fix.

> Thanks!
>    Toby

Best regards, Michael.