Obsolence of rlogin.el

Obsolence of rlogin.el

[Michael Albinus]

Hi,

I propose to mark rlogin.el as obsolete in Emacs 27. We don't need its
functionality any longer.

It's major functionality, an interactive shell on a remote host, is
available by a combination of Tramp (a remote default-directory), and
the `shell' command.

The other unique feature of rlogin.el, tracking directory changes, works
for local files in shell.el, and it works partly for remote files. In
rlogin.el it doesn't work proper, because remote files (for example in
compilation-minor-mode) are accessed by ange-ftp.

Instead of reworking rlogin.el it looks more promising to polish shell.el.
 
There is also the comment in rlogin.el:
 
;; FIXME?
;; Maybe this file should be obsolete.
;; https://lists.gnu.org/r/emacs-devel/2013-02/msg00517.html
;; It only adds rlogin-directory-tracking-mode.  Is that useful?

Comments?

Best regards, Michael.

Re: Obsolence of rlogin.el

[Kalman Reti]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

I use it every day with rlogin-program set to a non-default ssh client
(which isn't suitable for other ssh uses, e.g. in tramp), so I would be sad
if it went away. Using shell with the default directory couples the remote
execution with remote file access which I find undesirable. It is not very
performant in the environments I use to access remote files via tramp.
Using rlogin, I can do m-x cd to set the default directory for the rlogin
buffer to a local (i.e. on the machine running emacs) path of the same
filesystem I am using on the remote machine. In this case tracking of
directory changes works correctly but I also have fast (local) tab
completion and file opening.

On Mar 21, 2018 9:11 AM, "Michael Albinus" <michael.albinus@gmx.de> wrote:

Hi,

I propose to mark rlogin.el as obsolete in Emacs 27. We don't need its
functionality any longer.

It's major functionality, an interactive shell on a remote host, is
available by a combination of Tramp (a remote default-directory), and
the `shell' command.

The other unique feature of rlogin.el, tracking directory changes, works
for local files in shell.el, and it works partly for remote files. In
rlogin.el it doesn't work proper, because remote files (for example in
compilation-minor-mode) are accessed by ange-ftp.

Instead of reworking rlogin.el it looks more promising to polish shell.el.

There is also the comment in rlogin.el:

;; FIXME?
;; Maybe this file should be obsolete.
;; https://lists.gnu.org/r/emacs-devel/2013-02/msg00517.html
;; It only adds rlogin-directory-tracking-mode.  Is that useful?

Comments?

Best regards, Michael.

[-- Attachment #2: Type: text/html, Size: 2180 bytes --]

Re: Obsolence of rlogin.el

[Michael Albinus]

Kalman Reti <kalman.reti@gmail.com> writes:

Hi Kalman,

First of all let me say, that I don't intend to damage anybody's
workflow. That's why I have asked here.

> I use it every day with rlogin-program set to a non-default ssh client
> (which isn't suitable for other ssh uses, e.g. in tramp), so I would
> be sad if it went away.

That's not completely true. It isn't documented in Tramp how to use an
alternative ssh client, but it's possible. So pls give me some
information how this ssh client is invoked, and we'll find out how to
configure this in Tramp. (And I should document this finally,
long-lasting point from my TODO.)

> Using shell with the default directory couples the remote execution
> with remote file access which I find undesirable.

That I don't understand. Which kind of remote file access do you have in
mind? We're speaking 'bout rlogin, which opens a remote shell, and let
you enter shell commands.

> It is not very performant in the environments I use to access remote
> files via tramp. Using rlogin, I can do m-x cd to set the default
> directory for the rlogin buffer to a local (i.e. on the machine
> running emacs) path of the same filesystem I am using on the remote
> machine. In this case tracking of directory changes works correctly
> but I also have fast (local) tab completion and file opening.

But in this case I fail to understand what rlogin is good for you. If
you access local files, you don't need this.

Maybe you could give me a short scenario how you work with rlogin?

Best regards, Michael.

Re: Obsolence of rlogin.el

[Kalman Reti]

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]

On Mar 21, 2018 12:04 PM, "Michael Albinus" <michael.albinus@gmx.de> wrote:

Kalman Reti <kalman.reti@gmail.com> writes:

Hi Kalman,

First of all let me say, that I don't intend to damage anybody's
workflow. That's why I have asked here.

> I use it every day with rlogin-program set to a non-default ssh client
> (which isn't suitable for other ssh uses, e.g. in tramp), so I would
> be sad if it went away.

That's not completely true. It isn't documented in Tramp how to use an
alternative ssh client, but it's possible. So pls give me some
information how this ssh client is invoked, and we'll find out how to
configure this in Tramp. (And I should document this finally,
long-lasting point from my TODO.)

> Using shell with the default directory couples the remote execution
> with remote file access which I find undesirable.

That I don't understand. Which kind of remote file access do you have in
mind? We're speaking 'bout rlogin, which opens a remote shell, and let
you enter shell commands.

> It is not very performant in the environments I use to access remote
> files via tramp. Using rlogin, I can do m-x cd to set the default
> directory for the rlogin buffer to a local (i.e. on the machine
> running emacs) path of the same filesystem I am using on the remote
> machine. In this case tracking of directory changes works correctly
> but I also have fast (local) tab completion and file opening.

But in this case I fail to understand what rlogin is good for you. If
you access local files, you don't need this.

Maybe you could give me a short scenario how you work with rlogin?


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.


Best regards, Michael.

[-- Attachment #2: Type: text/html, Size: 4029 bytes --]

Re: Obsolence of rlogin.el

[Michael Albinus]

Kalman Reti <kalman.reti@gmail.com> 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.

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?

Best regards, Michael.

Re: Obsolence of rlogin.el

[Kalman Reti]

[-- Attachment #1: Type: text/plain, Size: 3578 bytes --]

On Mar 23, 2018 12:56 PM, "Michael Albinus" <michael.albinus@gmx.de> wrote:

Kalman Reti <kalman.reti@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 4887 bytes --]

Re: Obsolence of rlogin.el

[Michael Albinus]

Kalman Reti <kalman.reti@gmail.com> writes:

Hi Kalman,

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

My idea is to use the "primary host" declaration of a cluster in
shadowfile.el. It shall be possible to declare the local host as the
primary host (no Tramp involved at all) of a clster. And if a file from
any host of the cluster is asked for visiting, the corresponding file
from the primary host, the local file, shall be taken. This would mimic
what you do with your rlogin setup, w/o the hack to redirect directory
tracking as you do. This would even free you from the precondition, that
a given file must be exactly on the same directory location on the
remote and local hosts.

shadowfile.el does not sync all cluster files automatically, once you
have edited one of them. You could configure it this way, but you could
configure it also differently, that it does it only when you call
shadow-copy-files. This said, you could even keep your approach to
distribute the changed local file to the involved remote hosts outside
Emacs.

> I think I wasn't being clear; I don't WANT to use tramp.

If you don't want to use Tramp at all, I cannot help you. It would be
the precondition to use directory tracking in `shell'.

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

Even after rlogin.el has been declared as obsolete, you could still use
it. It will be moved into the directory lisp/obsolete, and Emacs
maintainers won't feel obliged anymore to maintain it, fixing
bugs. That's all.

Best regards, Michael.

Re: Obsolence of rlogin.el

[Paul Eggert]

On 03/21/2018 06:10 AM, Michael Albinus wrote:
> Instead of reworking rlogin.el it looks more promising to polish shell.el.

Sounds good to me.