Tobias Muhlhofer <[email protected]> writes: [Still Cc'ing [email protected]. 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. _______________________________________________ Tramp-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/tramp-devel
