[ESS] ess-remote trouble
davison at stats.ox.ac.uk
Tue Feb 9 00:46:56 CET 2010
Stephen Eglen <S.J.Eglen at damtp.cam.ac.uk> writes:
>> I really like the idea of ess-remote, and I want to start using it
>> routinely. Unfortunately with my current set-up the remote session
>> buffer invariably eventually ends up with an inactive prompt. I haven't
>> noticed any particular pattern in when this happens (but so far I have
>> always got several minutes of correct functioning before it fails).
>> The steps I'm using are:
>> 1. M-x shell (on machine running ubuntu 9.10)
>> 2. ssh remote machine (fedora 10)
>> 3. R
>> 4. ess-remote
>> 5. r
>> 6. ...
>> I'm afraid I haven't yet managed to collect any helpful debugging
>> info. I tried using ssh -v and monitoring stderr but nothing relevant
>> appeared. Also nothing relevant in *Messages*. I don't have any problems
>> maintaining gnome-terminal bash ssh sessions open on the remote machine,
>> and as far as I know not with M-x shell ssh, although that's not
>> something I do often.
>> So at the moment I'd like to ask: Does anyone have any idea what's going
>> wrong? Is anyone else having similar problems? How should I debug
> I recently (a few weeks ago) patched ess-remote as I found it wasn't
> working for me, with steps similar to yours (omiting the 'ssh machine'
> 2010-01-18 Stephen Eglen <stephen at gnu.org>
> * essd-els.el (ess-remote): Use `ess-current-process-name' as the
> local process name if none passed to ess-remote.
> Are you able to test a new version of ess-remote to check this isnt the
I'm already using revision 4268, which contains the line
(setq ess-local-process-name (or proc-name ess-current-process-name))
>> 1. The behaviour of C-z isn't quite the same: when an ESS buffer is
>> associated with a 'normal' iESS buffer, the frame is split on issuing
>> C-z. But when associated with a remote buffer, C-z switches buffer
>> with no frame splitting.
> Hmmm... what is C-z bound to in each case?
ess-switch-to-end-of-ESS in both cases.
I've investigated this a bit. The behaviour diverges on line 777 of
depending on whether buf is "*R*" or "*shell*". I *think* that a
solution might be to change this line to
(display-buffer buf t)))
; at least, this appears to make *shell* and *R* behave the same in the
few tests I've done, but I don't know what other effects it might have.
The divergent behaviour happens because in display-buffer, at line 1095
in window.el we have
((and can-use-selected-window (same-window-p name-of-buffer))
the second condition (same-window-p name-of-buffer) is nil in the case
of name-of-buffer being "*R*" but non-nil in the case of "*shell*",
because the value of the variable same-window-buffer-names is
("*Python*" "*shell*" "*mail*" "*inferior-lisp*" "*ielm*" "*scheme*")
i.e. it includes "*shell*" but not "*R*".
>> 2. Entirely trivial but perhaps we could have 'R' as a synonym of 'r' at
>> step 5 above?
> Yes - or perhaps replace r with R?
More information about the ESS-help