[ESS] ess-remote trouble

[Dan Davison]

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[1]. 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
>> this?
>
> 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'
> step).
>
> 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
> problem?

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
ess-inf.el at

	(display-buffer buf)))

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*".

Dan

>
>> 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?
>
> Stephen