It's well known that emacs can be used as a terminal emulator (while itself is running in a terminal emulator), thus making it a valid alternative to more traditional terminal-in-a-terminal approaches, such as tmux or screen. However, there's one thing that could be done easily with the latter and I've found no alternative in emacs' term for this one so far.
Both tmux and screen can detach from a terminal and all tasks ran in their windows continue to run in background. It's done using C-b, d in tmux and C-a, d in screen by default. Later, I can return (reattach) to the terminal I've detached from by running something like tmux attach or screen -r. Also, sessions run in both of these terminal multiplexers are persistent - i.e. if I'm connected to some remote terminal and connection fails, I can reconnect and reattach to the terminal without losing any of my work - it really helps in case of faulty network link that occasionally breaks ssh connections.
Is there something like that available for emacs? Basically, I'd want to be able to:
Detach from emacs and leave it running in background with all the sub-processes ran in term buffers intact.
Reattach to it later and find all my processes running.
Automatic detachment of emacs from terminal on receiving a SIGHUP.
Use emacs daemon:
$ emacs --daemon
Then simply launch a new frame, equivalent for screen -x:
$ emacsclient -t
Related
On a Mac OS, I am able to run Emacs as a daemon and then the emacs binary. But, according to "Mastering Emacs" of Mickey Peterson (see the quote below), I should not be able to do that. Where do I misunderstand the book?
emacs --daemon will run Emacs as a daemon. It will call server-start,
as above, but will return control to your terminal immediately and run in the background, waiting for client
requests.
If you go the server route, you cannot use the default emacs binary
any more.
On a Mac Os, I launch Emacs with "/Applications/Emacs.app/Contents/MacOS/Emacs" from the command line.
The quote is misleading. After you have started a server you can happily run either emacs or emacsclient as you wish. The latter will connect to your server; the former will (as usual) start a new separate instance of Emacs.
I have been using emacs with tramp for a few weeks now to ssh into a server and edit some files. I do this by C-x C-f /ssh:username#server.com. Suddenly this has stopped working. I am getting "Waiting for prompts from remote shell problem" message.
However, If I don't provide a username (C-x C-f /ssh:server.com) then the connection seems to get established.
I am running emacs 24 using cygwin. How can I get this connection to work again?
There is one relatively common reason (at least on Windows/Cygwin platform): the ssh process started by tramp gets somehow stuck and unresponsive.
On my current desktop this happens once every month or so.
Just kill any ssh processes, either from your favourite cygwin terminal (with kill -9) or from your Windows task manager. This gets everything working again.
I have never encountered this problem on Linux, only on Windows/Cygwin.
I'm running a terminal inside emacs, using term-mode. In that terminal I'm ssh-ing to another host and on that host, the backspace key no longer works. It works fine if I'm ssh-ing from a different terminal emulator outside of emacs.
So just to be clear, I'm not running emacs on the remote host, I'm running a remote shell inside emacs.
So it is your terminal in emacs you need fix, :D
I had a similar issue with a perticular setup where backspace key through ssh act as delete key, seems emacs sometime have problem guessing which one is which in non-GUI setting.
what I did is change (normal-erase-is-backspace-mode 1) from 1 to 0. You could try that, but is sounds like a terminal issue to me.
reference in emacs manaul about that setting
I am already using Emacs server for some of the problems described in the documentation, For example, I have (server-start) in my .emacs init file, and I have set the EDITOR env. variable to emacsclient so that git and other programs don't open a new instance of Emacs when they need me to type text or log message. This is working great so far.
I am now wondering if I can use Emacs server for something else: I often launch Emacs remotely through an ssh -X session. Sometimes I need to close the ssh session (e.g. I need to reboot my local computer) and re-connect. It would be great if instead of fully closing Emacs for this, I could detach from Emacs, and reattach later.
Is this possible with Emacs server? I believe from things I have read online that the answer is yes, but:
My question:
How can I safely detach from an Emacs server and reattach later?
If you directly start Emacs from within the SSH session, you cannot gracefully detach, because the Emacs process becomes part of the process group created by the remote shell, and if the shell exists it will terminate all processes in its process groups.
However, you can start Emacs in Daemon mode first, with emacs --daemon. Emacs will load the configuration, start an edit server (even without an explicit (server-start) in your configuration), and detach from the terminal. This Emacs daemon will stay alive across different SSH session.
Subsequently, only use emacsclient to connect to the running daemon.
emacs --daemon or (server-start) in .emacs.
Next use emacsclient file, emacsclient -n file or emacsclient -c for just an attaching.
To leave attach as usual C-x C-c.
When I start the `Paste' web server in daemon mode, it seems to kill off it's ability to reload when the timestamp of a source file is updated.
Here is how I start the daemon...
cd ${project} && ../bin/paster serve --reload --daemon development.ini; cd ..;
...which defeats one of the main points of using Paste (for me).
Has anyone come across this or know what I'm doing wrong?
To be complete, the file that I'm changing is a controller file.
The version is `PasteScript 1.7.3'
I believe that the two options are essentially incompatible, since the reloader stops the server with a SIGTERM and the daemon-ized server is impervious to that -- and since daemon is intended for running in a production environment, and reload for a development/debugging environment, I guess that their incompatibility is not seen as a big loss. I imagine a customized reloader, tailored to properly stop and restart the daemonized server, could certainly be developed, but I don't know of any existing one.
I had a similar problem and circumvented the problem. I currently have paster running on a remote host, but I am still developing, so I needed a means to restart paster, but manually by hand was too time consuming, and daemon didnt work. So I always had to keep a shell window open to the server and running paster without --daemon in there. Once I finished my work for that day, and i closed the shell, paster died, which is bad.
I circumvented that by running paster non daemonized in a "screen".
Simply type "screen" in your shell of choice, you will usually depending on your linux be presented with a virtual terminal, that will keep running even when you log out your remote session. Start paster as usually in your new "window" (the screen) with --reload but without daemon, and then detach the window, so you can return to your normal shell (detach = CTRL-A, then press D). You can re-enter that screen by typing "screen -r". If you would like to kill it, reconnect it (screen -r) and inside the screen type CTRL-A, then press K.
Hope that helps.