I find myself doing this often:
launch emacs
shh into a server by C-x C-f [RET] /ssh:me#aserver.com:filetoedit.py [RET]
C-x 2 to split windows
C-x o to switch to top window
M-x shell to start a shell on my ssh connection
I there a way to automatically replicate this process on startup? M-x desktop-save doesn't seem to be doing this for me.
Despite my enthusiasm for emacs, I recommend you to take a look at "tmux".
You run emacs in tmux only once. Later on, say when you are back in the office the next day, you simply re-attach to the tmux session and will find your emacs instance is still there.
You don't really specify a lot about your setup, and I agree tmux may help. In my case, I do a version of what you are asking about daily. I'm running GUI emacs 24 on my Mac, I'll be connected to work via VPN with several tramp buffers and shells open. Then I'll just sleep the Mac, commute to work, re-establish the VPN connection and then continue as if nothing happened with the tramp buffers, and after running M-x shell in the shell buffers, continuing as if nothing happened.
To repeat this for several file/shell pairs I would probably save the window config to a register with C-x r w X and C-x r j X for different values of X.
Related
Some time ago I opened a file via tramp. That is, effectively via ssh/scp. It still is not finished and I would like to stop the reading. Yet C-g does not work. Apart from killing emacs (which seems quite unethical to me, it also destroys my M-x shell s), do I have any other option to stop the loading?
Note that the server does not hang. And I do not want any timeouts like in this question.
If you can find the corresponding ssh / scp process ID, you can kill just that.
If neither C-g nor C-cC-c are interrupting, but Emacs is still responding to M-x commands, you can kill the connection or the whole buffer.
The TRAMP manual suggests that the following M-x commands may be of interest:
M-x tramp-cleanup-this-connection
M-x tramp-cleanup-all-buffers
I'm trying, for the first time, to access remote files via tramp from Emacs on Windows. I'm trying to open a remote directory via C-x C-f /plink:user#host:/. However, when Emacs gets to "Tramp: found remote shell prompt" in the minibuffer, it hangs. And not only does the minibuffer hang, but all of Emacs hangs, so that I have to kill it via task manager. This unfortunately means that I can't see any debug information for tramp, because it outputs to an Emacs buffer. How can I go about debugging this?
I'm running Windows 8.1, Emacs 24.3, and plink 0.63.
I ran into a very similar situation with tramp ssh, and I can't guess at what your particular problem is, but only that you can get a complete trace by doing:
(setq tramp-verbose 10)
Then try the connection again, and after it hangs, C-g and check for a buffer:
*debug tramp/plink USER#IP*
The level 10 verbosity might be too overwhelming - you can experiment with lesser levels (smaller numbers) to see if it reveals what the problem might be. Check the docstring for tramp-verbose.
Good Luck!
How do you close an emacsclient frame without killing the server/daemon?
Doing C-x C-c or C-x 5 0 in the gui will exit both frame and server (and other clients), while this just quit the current frame when done from terminal.
(Ps: My emacs version is 24.2,gtk. I've tried without init-file to see if it was coming from my config, but results were the same)
From the minibuffer, when emacsclient starts:
When done with a buffer, type C-x #
I think the key point here is you need to start the server in daemon mode. If the server runs in an existing emacs process - for instance if you have (server-start) in your init file - the server dies with the emacs process.
There are a couple of ways of starting the server in daemon mode:
call emacs with the --daemon command line option
call emacsclient with the --alternate-editor="" command line option, which will in effect run emacs --daemon for you then attempt to connect to it
Once you have the server in daemon mode, you should be able to close any frames and the daemon will continue to sit and wait for further connections.
Starting the emacsclient with -n/--no-wait flag will:
Don't wait for the server to return
You won't need to close the client in that case.
And if you have to a close emacsclient just kill the buffer the server will remain intact.
Because you ran (server-start) from an existing frame, that frame is not an emacsclient frame, and closing the last such frame evidently gets the same treatment as C-x C-c: it will exit Emacs.
If you used emacs --daemon, possibly using the ALTERNATE_EDITOR='' trick, you would not have this problem; you could just use emacsclient -n -c to open a GUI frame, and after closing it the daemon would just sit around waiting for you to open a new frame, whether graphical or terminal-based.
I am using both Debian with i3, and OSX. I usually exit emacsclient GUI frame by the window manager's close window shortcut. For example, in OSX, I use "Command + w" to close the client GUI frame without killing the server, and in i3, I use "Super + Shift + q" (the default close window by i3) to exit the client frame.
In modern version GNU Emacs(27+), it says
When done with this frame, type C-x 5 0
Occasionally when using emacs in term mode I will mistakenly run emacs file instead of just opening the file. This will create a nested emacs client inside the current client. My problem is how to close the inner client only?
Answer
You should be able to C-z out of it, then kill it with
kill %1
Explanation
C-z will suspend the current process, assigning it a job number and returning you to the shell.
The jobs command will show you the current jobs and their numbers. kill allows you to kill a process by its job number using the %n syntax.
Just use the command M-x kill-emacs inside the inner emacs. Backgrounding and killing it works fine but it is a little bit more hackish.
You should use the top Emacs. Starts emacs with:
emacs --daemon
Starts all frame with:
emacsclient -c
From your term:
emacsclient -n
Or you should use eshell instead.
Assume you work on a remote server from a local emacs shell (started with M-x shell). If you execute a process which takes too long (for example an ls in a directory with a huge amount of files), you would like to stop that process (in the terminal one would use control-c). I tried C-c C-c but that kills the whole shell... How can I only kill the running process on the remote server and not the whole shell?
Update
Step-by-step:
1) M-x shell (execute on local machine)
2) ssh mylogin#myremotemachine.foo.bar (execute on local machine)
3) sleep 60 (execute on remote machine)
4) C-c C-c (execute in the current shell)
=> instead of still being on the remote host and just the sleep command being killed, the whole remote connection is closed and you are on your local machine again.
When I follow the steps you listed, I find myself back at the remote shell prompt. I'm using Emacs 23.1.1.
I find that typing C-q C-c RET also interrupts the remote process, again leaving me at the remote shell prompt. You might try that as an alternate approach.
It is unclear to me if you want to kill the command from within emacs, but you could alternately open another connection or window (if you are using screen or tmux) and perform the standard
ps aux | grep hungprocess
and then
kill hungprocess_pid
For some reason I kept thinking that such a method wouldn't work and that I'd end up taking down emacs as well. I have used such a method multiple times when I haven't set up my gpg pinentry agent when opening a gpg encrypted file in emacs. Emacs/gpg will try to spawn a GUI and therefore hangs emacs, waiting for input in the GUI when I am remotely ssh'ed in.