# emacs opens shells in a random window, how to change this?

Try splitting the frame repeating some times the command C-x 3. Then try open the shell with M-x shell.

It will open in a random window and not the one which you have typed the command from. Why?

• For the functions that I use on a daily basis, like shell/eshell, I created new functions that do not display the shell/eshell buffers -- i.e., just locate and populate the buffer, but do not select or display it in any particular window. Then, I have my preferred method of displaying them with other functions that target a specific frame and a preferred window layout, or I can chose to display the buffer in an existing or new window to the left/right/up/down, whatever floats my boat and I'm not restricted to pop-to-buffer or trying to make it behave differently than it was designed. – lawlist Aug 7 '17 at 2:23
• Wow, can you post your configuration please? – Nisba Aug 7 '17 at 14:17
• Here is the link to a previous answer that I posted in a related thread: emacs.stackexchange.com/a/28924/2287 – lawlist Aug 7 '17 at 15:20

The reason is that shell uses pop-to-buffer.

If you want to use the selected window try this in your config.

(add-to-list 'display-buffer-alist
(,(rx bos "*shell*")
display-buffer-same-window
(reusable-frames . visible)))


The following works well in my GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23) of 2017-12-09

(add-to-list 'display-buffer-alist
(,(rx bos "*shell*")
display-buffer-same-window))


However, with the answer provided by @bertfred I get the error

(wrong-type-argument window-live-p nil)


EDIT:

Here is the content of the *Backtrace* buffer after M-x shell with @bertfred's suggested display-buffer-alist:

Debugger entered--Lisp error: (wrong-type-argument window-live-p nil)
select-window(nil nil)
pop-to-buffer(#<buffer *shell*>)
shell(nil)
funcall-interactively(shell nil)
call-interactively(shell record nil)
command-execute(shell record)
execute-extended-command(nil "shell" "shell")
funcall-interactively(execute-extended-command nil "shell" "shell")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)

• Are you able to reproduce this with emacs -Q? If so, you should consider sending an M-x report-emacs-bug RET. Either way, you can try debugging this yourself by typing M-x toggle-debug-on-error RET before invoking the error. – Basil Feb 2 '18 at 2:41
• Dear @Basil, yes I can reproduce this error with emacs -Q. However, I am hesitant to file this as a bug since I barely understand the inner workings of display-buffer-alist. – Ruy Feb 2 '18 at 10:47
• Does toggle-debug-on-error shine any light on what is causing the error? I cannot reproduce your error on any version of Emacs. – Basil Feb 2 '18 at 10:48
• Dear @Basil, in case you are interested, I added the debugger's output to my answer. It was produced under emacs -Q, as you suggested. Does it say anything to you? – Ruy Feb 3 '18 at 13:22
• I didn't read your answer carefully enough, and wrongly thought the error was caused by your code, not bertfred's. It is unsurprising that bertfred's solution does not work because it is wrong to use switch-to-buffer in display-buffer-alist, as its docstring (via that of display-buffer) explains. Sorry for the confusion and wasting your time. I will edit bertfred's answer and you can remove the debugging information from yours. – Basil Feb 3 '18 at 13:40