tags:

views:

1107

answers:

8

I started using emacs as my main editor a few days ago, and I'm in the process of gathering all customizations I need.

The main usage I'm giving it is for development of a C project on a remote Linux machine (RHEL 5). So far I was using plain vim (only as a text editor) and a bunch of shell scripts, and one day I decided I would try emacs. So far I like it.

But as a drawback I see that setting up the environment to run emacs is a long way to go, and instead of using it directly on the development machine (and set up the environment on every machine I use) I would try to just use it from my laptop and do the remote development.

I know about TRAMP but that only edits remote files as far as I know. The big obstacle is running shell commands on the remote machine with a single keystroke (I bound F5 to run a custom compile command on the remote machine's emacs).

How do you run shell commands on a remote machine with a single emacs keystroke? Do you know any other tips & tricks to do full remote development?

+9  A: 

When doing remote development, I use screen which provides multiple virtual remote terminals available at the press of a couple of keys. This is indispensable for me. Not only does it provide virtual terminals, but your session is preserved on the server if your connection drops for any reason.

See the GNU Screen Survival Guide question for more information about getting started with screen.

I usually have one terminal open for source control operations, one for editing, one for compiling (I just have to switch to it and hit UpArrow+Enter), and one for debugging. Depending on the environment and application I'm working on, I may have more or fewer than this, but that's the general layout.

Greg Hewgill
+13  A: 

TRAMP supports compilation and debugging on the remote machines (on which the files reside). This should be automatic and relatively seamless. Check out the documentation for remote processes.

Trey Jackson
+5  A: 

Don't worry. You can run anything in Emacs with a single keystroke. Others have noted ways you can do this elegantly with TRAMP, but if that doesn't suit (for whatever reason) you could also just cook up your own function using:

(defun arbitrary-remote-command ()
  (interactive)
  (shell-command
   "ssh user@remotehost arbitrary-command"))


(global-set-key (kbd "<f5>") 'arbitrary-remote-command)
Matthew Flaschen
+1  A: 

Assuming you don't want to run emacs in terminal mode on your remote machine then it's fairly easy. As you know you can use TRAMP to edit remote files. I just set compile-command to 'ssh me@remote "cd /path/to/root && make"' and be done with it.

stsquad
+1  A: 

I would just ssh into the remote machine and run emacs in terminal mode instead of using TRAMP. TRAMP is really slow when you don't expect slowness, at least in my experience. I have also seen it fail in weird ways, and it is not always obvious how to "fix" it. If you ssh in, you won't be able to use emacs UI stuff, like the menus etc, but since you are used to vi that should not be an issue for you. In fact, you can just turn them off so that your ssh emacs experience is very similar to your local experience (if local != terminal mode) (1).

Using screen may be useful if you care about preserving your session in case the connection drops - apart from that you get similar functionality as virtual terminals with emacs buffers. For example, you can open many shell buffers and run various shell commands in emacs buffers. I use this to run many instances of sqlplus (use rename-buffer to give them all nice, friendly names).

Since you are ssh'd into the remote machine, you don't need to worry about running "remote" shell commands.

On the other hand, I am not sure what you mean by "I see that setting up the environment to run emacs is a long way to go". If you have source control, this should be trivial...(I bet you have a good reason).

(1) turn off menu, tool bar and scroll bars:

(if (fboundp 'menu-bar-mode) (menu-bar-mode -1))

(if (fboundp 'tool-bar-mode) (tool-bar-mode -1))

(if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))

killdash10
I'm currently doing development this way, but for example to set up w3m to work in order to see online documentation I need a bunch of rpm's to install and resolve dependencies, or compile cedet (there's no yum). Part of the development is testing an installer on a recently formated system, so every now and then the server is formated and I need to install emcas all over again. Or, I need to change some code on another server, and I would need to install emacs also. With vim there's no problem because it's there "out of the box" (at least as a simple text editor).
German
A: 

Two cents: if bandwidth is not a big concern, I would give a crack at VNC.

+1  A: 

Nice answer from Trey Jackson, but the answer from Matthew Flaschen actually helped me more.

I couldn't find a way to get TRAMP do the compiling, but accidentally I found the command remote-compile.

Now I just add these lines to my .emacs:

(setq remote-compile-user "root")
(setq remote-compile-host "localhost -p 3000")  ;This is just when tunneling
(setq compile-command " cd /usr/src/nexus/traffic && ./builder.sh compile ; cat builder.log")
(global-set-key (kbd "<f5>") 'remote-compile)

And before doing anything, set up the ssh connection using ControlMaster and I don't have to type passwords.

Summarizing:

  • Editing remote files: TRAMP
  • Multiple terminals saving states: SCREEN
  • Define emacs keybindings to execute remote commands: See Matthew Flaschen response
  • Remote compiling: Command remote-compile with ControlMaster

I think that covers some important actions to do remote-development.

German
A: 

I've tried TRAMP before for a situation like yours, but I too found it failing in strange ways, and slow in general.

I am now using Emacs to edit files mounted over an sshfs mount. This works very well for me.

To mount the remote file system (assuming you have the host set up correctly in .ssh/config and set up public keys to connect without a password)

$ sshfs remote:dir localdir

and edit as you like from then on!

As for compilation, see the other answers, they cover this in full.

yhager