When I type emacs & in X11, a new window doesn't open. Instead I just get the PID of the process. This illustrates what I mean.
bash-3.2$ emacs &
[1] 38624
Why is this happening and how can I get emacs to open in a separate window?
You can't start terminal Emacs as a background job -- it needs to interact with the terminal. Whenever a background job attempts to write to the tty, it is immediately stopped.
I would expect that your next input into the terminal would have resulted in a message similar to this?
[1]+ Stopped emacs
(which would have been useful).
You could then foreground the job with fg.
Running emacs & only makes any sense with GUI Emacs.
Related
On my Windows, I managed to get sublime text become a command on my MINGW terminal. I'm able to open sublime text itself or open sublime text with a text file. However, the terminal won't accept more commands until I close the terminal. It's similar to calling vim, where vim needs to exit before it accepts more commands. But sublime is its own window, so there's no reason for a terminal to wait. What is the way to configure a command in such a way that we don't wait for it to terminate before the terminal accept more commands?
Is it a bash compatible shell?
The most obvious way of doing might be to append an & to the end of
the command. This detaches the command from stdin which means the
shell isn’t tied up by the command and you can execute other commands.
However, the command's process is still managed by the shell and
stdout and stderr are still attached to the shell session. This means
that when the shell session ends (you close your terminal window, exit
ssh, etc) the command’s process is sent a HUP signal, which usually
terminates the command.
Refrence:
Running bash commands in the background properly
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
When using start-process with Emacs on Windows XP, deleting the process or killing Emacs also kills the subprocess -- e.g., viewing a PDF with another application.
How would one go about removing a process from the list of active processes within Emacs, without sending a kill signal to the subprocess -- i.e., leave the subprocess running, but tell Emacs to forget about it?
Here is a related thread that discusses using w32-shell-execute as an alternative to start-process: In emacs, how to execute external command not as a emacs process? I have verified that w32-shell-execute is a viable alternative for Windows XP.
I am very fond of start-process and would still be interested in knowing (please) whether it is possible to delete a process from Emacs without killing the corresponding subprocess.
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.