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
    Commented Aug 7, 2017 at 2:23
  • Wow, can you post your configuration please?
    – Nisba
    Commented Aug 7, 2017 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
    Commented Aug 7, 2017 at 15:20

2 Answers 2


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*")
               (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*")

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

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


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*>)
  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)
  • 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
    Commented Feb 2, 2018 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
    Commented Feb 2, 2018 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
    Commented Feb 2, 2018 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
    Commented Feb 3, 2018 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
    Commented Feb 3, 2018 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.