Re: Obsolence of rlogin.el

[Kalman Reti]

On Mar 23, 2018 12:56 PM, "Michael Albinus" <address@hidden> wrote:

Kalman Reti <address@hidden> writes:

Hi Kalman,

> I build and test a single set of sources on a dozen different
> platforms; each platform copies its sources from a 'master' sandbox
> (so I am certain all have the exact same sources).
>
> I have elisp code that generates a dozen rlogin buffers (to all the
> platforms) and other functions which send commands to all of them and
> analyze what comes back, e.g. build or test failures. If I have to
> make changes, I make them to files in the 'master' sandbox which
> resides on a shared filesystem (either nfs or samba, depending upon
> whether my emacs is running on linux or windows) that is local as far
> as emacs is concerned. The hierarchy of files in the sandboxes on the
> various machines mirrors the hierarchy of that master sandbox, so I
> m-x cd the corresponding master patch to each rlogin buffer, so
> opening a source file opens the corresponding master source file, not
> the one in the remote sandbox. Tab completion of common files works
> because I only do relative cd'ing inside each of the shells. If I need
> to look at a generated file on the remote machine, I explicitly
> provide the host name, but that's fairly rare. It is important to me
> that if I open a file while the current buufer is any of the remote
> rlogin buffers, I get the canonical file from the master sandbox
> (which may already have been open previously). I don't know how to get
> this effect using tramp and/or remote shell buffers.

Sounds to me like you need shadowfile.el. With this package, you could
define clusters, which implement a similar feature as you apply, keeping
several files in sync on different hosts, once one of the files is
changed.

This sounds more like a 'keep files in sync wherever the changes are made' solution rather than a 'I want changes made only in the canonical location and distributed (non-automatically) to the subordinate locations at times of my choosing' solution. However, I'll look into it to see if it might be useful.

Unfortunately, shadowfile.el lacks the same problem as rlogin.el does:
it is based on ange-ftp. So it must be adapted to Tramp. I've started
this rewrite a while ago, but it is half-baken only. Maybe I shall
continue this work, with pressure from you :-)

For the time being, we could try to solve your other problem, that you
couldn't use Tramp due to your special ssh client. Do you like to send
me the details, that we could find out how to configure Tramp to
support you?

I think I wasn't being clear; I don't WANT to use tramp. If I am cd'ed into a particular source directory in the rlogin session on a remote host, I want c-x c-f to edit the source file in the corresponding directory in the master sandbox on the shared filesystem, not the local copy on that remote host. If I did that via tramp it would be horribly inefficient, going through the remote host to open a file that is also directly accessible to the emacs via a more direct route. Moreover, if I were to edit the same canonical file via tramp from two remote host rlogin buffers, I'd have two emacs buffers with the same file when I want just one, i.e. they would differ in hostname but in actuality would represent the same shared file.

Rlogin.el gives me exactly the two capabilities I want, executing remote commands and relative directory tracking without adding others that I don't want, e.g. a remote shell's interpreting pathnames as if they existed on the remote host.

Best regards, Michael.