On Mar 3, 2008, at 2:11 PM, Aaron J. Grier wrote:
On Sun, Mar 02, 2008 at 05:46:48AM -0800, Joshua Juran wrote:
*everyone* has access to said 'smart' terminals these days. (Anyone
still using a dumb terminal must be assumed to prefer it.) But
somehow, it's mysteriously difficult to make remote file editing not
suck. Or maybe nobody cares enough.
how do you want to disassemble the problem? remotely accessing a
running editor has existing hateful partial-solutions (X, screen,
remote
desktop). a local editor accessing a remote file has existing
partial-hateful solutions (SMB, NFS, FTP, HTTP). allowing the
"remote"
bits of file editing to be put into an editor would result in a
veritable plethora of hateful one-per-editor "remote file access"
implementations, which I'm sure emacs and vim have already
implemented.
Since the originating hate is the need to run a tty-based editor (all
of which are hateful, as well as the limitation in the first place),
my approach is to replace the remote-shell-invoked editor with
another program that spawns an editing session locally.
The problem with X11 is that you have to have the X11 client
installed on the remote host (and that it limits you to X11 clients,
which are all hateful to me). My suggestion is to have a single
wrapper program implement editor semantics which talks to remote-
editing client plumbing installed on the remote host, which talks to
remote-editing server plumbing on the local host, which invokes my
editor of choice, which now is not limited to X11 clients. It's
easily implemented over HTTP, and works over ssh if you manually
forward the port and trust all remote users.
Partial source code for your hating pleasure: <http://
lamp.cvs.sourceforge.net/lamp/jTools/local-edit-client/>
Josh
