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:

> Michael:

Hi Tobias,

> First, thank you for the quick reply.
>
> Your test setup seems appropriate to me. As for versions, I'm using
> ESS 12.09 (which seems to be their latest and happens to ship with
> Fedora, which I use). I have tried this on three different remote
> servers with slightly different setups and have still run into the
> same issue.
>
> For whatever it's worth, I didn't have this problem, last time I used
> this procedure (which was several months ago). Of course, in the
> meantime there are probably new versions of just about everything,
> including Tramp, but also Emacs and ESS which I realize makes things
> difficult to track down.

Well, running tests on my Fedora 18 machine. Still using Emacs 24.3.50 /
Tramp 2.2.7-pre, the developers versions.

With ESS 12.09 as brought by Fedora I have exactly the same problem as
described by you.

Then I have installed ESS 5.14. No problem, it works as expected.

Switching back to ESS 12.09. Running the same scenario, but starting 
"M-x shell" and R on the local host. And voilà, the same problem.

> One more thing; a similar phenomenon appears in the following situation.
>
> 1) Use Tramp to open a remote R file for editing (i.e. C-x C-f
> /<username>@<server>:/<path-to-file>).
> 2) Start an R session with M-x R. In that case the newest default
> behavior is to want to start the R session on the remote machine (by
> suggesting a tramp remote starting directory there). Do that.
> 3) You get asked for your password.
> 4) Spinning "Emacs waiting" icon appears and never goes away. Maybe
> Tramp managed to log in, started R, and tried to feed some code. Maybe
> something else, though.

This I cannot confirm. With this scenario, I get a buffer *R* like this:

--8<---------------cut here---------------start------------->8---
R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows"
Copyright (C) 2012 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> assignInNamespace(".help.ESS", help, ns=asNamespace("base"))
> options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient', 
> show.error.locations=TRUE)
> 
--8<---------------cut here---------------end--------------->8---

"R version 2.15.1" is the installed version on the remote machine. On my
local Fedora 18, there is "R version 2.15.2". So I'm pretty sure that
the remote R interpreter is launched.

Then rerunning the test with Fedora's Emacs 24.2.1 / Tramp 2.2.3-24.1.
Same result.

This gives me an idea. I do the following:

- Start Emacs
- Load a remote R file
- Apply "M-x R"
- Apply "M-x ess-remote"
- Switch back to the buffer with the remote R file. Mark a region, and
  apply "C-c M-r"

It works! So I would say, that in ESS 12.09 there are changes, which
refuses to cooperate with an R interpreter started from a shell inside
Emacs. But an R interpreter started with "M-x R" still cooperates.

Likely you shall investigate, why "M-x R" does not work for you. Start
with a local file / local R process. If this works, and the remote case
doesn't, set tramp-verbose to 6 and show the resulting debug buffer.

In order to reduce side effects, run your tests with

emacs -Q -L /usr/share/emacs/site-lisp/ess -l ess-site

> Thanks for the help!
>    Toby

Best regards, Michael.