Using emacs across many hosts

On a daily basis I:

1. use multiple workstations runni开发者_运维知识库ng either Linux, Windows, or MacOS X
2. edit files on additional Linux hosts that are not any of the workstations mentioned above

The only common element here is that the internet connects all of these hosts: workstations and servers. I can keep all of the config files in sync on my workstations too and can run an X server on all of them. What's the right way of running emacs? I don't want to sacrifice any features.

In my ideal world I can type 'emacs foo.txt' on a remote host and some magic happens via X forwarding to display the file in my workstation's existing emacs session.

Non-solutions

1. tramp: when I'm manipulating a remote host an editor is just part of my workflow. I need a terminal open so I can run other commands quickly. tramp is all wrong for this.
2. ncurses emacs: sucks, I want the graphical kind

If you don't have a positive answer to my question, please don't just guess. Thanks.

---

Have you tried tramp with eshell? You can "cd /remote.host:/some/path" and edit files from there, and if you type a non-built-in, it fires up a ssh pipe to run it. Quite slick.

---

I fail to see why tramp is not a solution. You can edit using tramp, and do whatever you need in a terminal using xterm+ssh.

---

Well, if you can setup X clients on your Windows and OSX boxes, you should be able to run an X version of emacs on any of those platforms and set the display back to your workstation. That would give you your nice WIMP interface.

However there are a couple of solutions to keeping a terminal open to the same box. One is to just telnet into it twice. Once for your emacs session, and once for a shell.

The other option of course is to use meta-x shell to bring up a shell buffer inside of emacs. A true emacs guru prefers to run their OS inside of emacs, rather than the other way around. :-)

---

The approach I use is based on source controlling the Emacs scripts and important common files (using Git). This gives me a consistent code base so I don't have to remember which host has which script or file (or version of what I'm looking for). Git is particularly well suited to supporting this mechanism and I've pretty much got in the habit of updating the master origin repo daily. Within the scripts (both Emacs and bash shell scripts) I use machine tailored code to handle local requirements. This system has been in place now for well over a year and I find it to be quite effective. This is a technique I've seen recommended for some number of years. I found it clunky with CVS and Subversion but git feels tailored for the job. That said, I like the solution you selected as a complimentary tool and look forward to adding that to the mix.