3 ms·

> if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there You don't need emacs on a server. TRAMP is built-in and can

> if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there You don't need emacs on a server. TRAMP is built-in and can open remote files in a local instance over SSH, SMB, FTP, ADB, or docker/podman.

pmontra 5mo ago
Yes, I can use TRAMP but as I ssh to the server anyway to run commands, I'm editing the files with vi there. Furthermore I'm sure I don't inadvertently edit the local version of the file instead of the remote one, or that I forget to kill the buffer with the remote file and edit it instead of the local one after a few days. What's on the server stays on the server.
rmunn 5mo ago
Never really learned emacs so didn't know TRAMP existed. When was it created? I was given that advice ("vi will always be available on the server") in the late 90's so I'm curious to know if TRAMP was an option my prof didn't know about (or didn't mention), or whether it was developed later and the advice was good at the time. EDIT: Found http://www.fifi.org/doc/tramp/tramp-emacs.html http://www.fifi.org/doc/tramp/tramp-emacs.html which mentions that TRAMP started development in November 1998. I would have been getting that advice in late 1997 or early 1998, given when I started my Unix class at college. So the answer appears to be that the advice was actually correct at the time, but superseded sooner than I thought it was.
- scbrg 5mo ago
  Well, TRAMP was preceded by ange-ftp, which let you edit files remotely over ftp. I was using that in 1995, and I didn't get the impression then that it was brand new, so it had probably been around for a while already. Of course, if your problem is "/usr won't mount", then it's likely that the ftp server isn't running either, so the advice still makes sense.
owl57 5mo ago
I often use vim despite knowing only a few basic commands because I'm already running various commands on the remote machine in the terminal and don't want the context switch. And because connection / file path completion in TRAMP is annoyingly slow if the server is far enough. As an extreme example, today I needed to combine parts of two files into one and decided that cat foo bar > foobar && mv foobar bar && vim bar of all things will better keep me in the flow than either googling how to insert one file into another in vim or starting up TRAMP.

pmontra 5mo ago

Yes, I can use TRAMP but as I ssh to the server anyway to run commands, I'm editing the files with vi there. Furthermore I'm sure I don't inadvertently edit the local version of the file instead of the remote one, or that I forget to kill the buffer with the remote file and edit it instead of the local one after a few days. What's on the server stays on the server.

rmunn 5mo ago

Never really learned emacs so didn't know TRAMP existed. When was it created? I was given that advice ("vi will always be available on the server") in the late 90's so I'm curious to know if TRAMP was an option my prof didn't know about (or didn't mention), or whether it was developed later and the advice was good at the time. EDIT: Found http://www.fifi.org/doc/tramp/tramp-emacs.html http://www.fifi.org/doc/tramp/tramp-emacs.html which mentions that TRAMP started development in November 1998. I would have been getting that advice in late 1997 or early 1998, given when I started my Unix class at college. So the answer appears to be that the advice was actually correct at the time, but superseded sooner than I thought it was.

scbrg 5mo ago
Well, TRAMP was preceded by ange-ftp, which let you edit files remotely over ftp. I was using that in 1995, and I didn't get the impression then that it was brand new, so it had probably been around for a while already. Of course, if your problem is "/usr won't mount", then it's likely that the ftp server isn't running either, so the advice still makes sense.

owl57 5mo ago

I often use vim despite knowing only a few basic commands because I'm already running various commands on the remote machine in the terminal and don't want the context switch. And because connection / file path completion in TRAMP is annoyingly slow if the server is far enough. As an extreme example, today I needed to combine parts of two files into one and decided that cat foo bar > foobar && mv foobar bar && vim bar of all things will better keep me in the flow than either googling how to insert one file into another in vim or starting up TRAMP.