Emacs: Preventing gud & pdb from controlling windows

Question

I'm using pdb to debug Python programs and am unhappy with it's behaviour.

I have the screen divided into multiple emacs windows, and when I execute pdb, it (randomly?) replaces one of the windows with the output of the *gud* debugger.

Also, when a breakpoint is encountered, even if the debugging buffer is already visible in a window, it usually puts this buffer into another window, and replaces another of my windows with the contents of the source file. (incidentally I like that it jumps to the correct line in the source file)

How can I disable gud/pdb from managing my windows for me? Is it possible in emacs to prevent all programattic manipulation of windows & screen layout?

Edit: I found the answer that partially solves this in another post: toggle dedicated windows

Crashaw

Answer 1

Look into sticky windows.

Mv

setting set-window-dedicated-p has the disadvantage that C-f find-file called from a window unintuitively opens the file in another windoow. I was able to override this behaviour by adding (set-window-dedicated-p (get-buffer-window (current-buffer)) nil) to a custom version of find-file – Crashaw

Sticky windows won't stop gud/pdb from trying to steal your sticky windows where your source code buffer reside. If gud/pdb can't steal the window, it will open a new Emacs Frame. See my answer for a solution to this problem. – Surra

Answer 2

I tried all these approaches without success on Emacs 24. If you are still interested I reverted to the old gdb behavior using 'gud-gdb' which implements the old behavior of gdb/emacs interaction (no dedicated-windows and no I/O buffer). If you don't want to call M-x gud-gdb when you use it, you can define an alias for M-x gdb

Delbert

Finally something that works with the latest version of emacs! – Mraz

Yes! gud-gdb works like I am used to. The new behavior is works well until it doesn't -- its failure leaves emacs in some weird state. – Theomachy

Answer 3

I have a solution that prevents the gdb from stealing windows. It works with Emacs 24.4 (2014-07-18 snapshot) and does not require dedicating buffers. The benefit over other answers is you won't have to bother dedicating and undedicating buffers whenever you change buffers, which quickly becomes tedious.

Place this advice in your .emacs:

(defadvice gdb-inferior-filter
    (around gdb-inferior-filter-without-stealing)
  (with-current-buffer (gdb-get-buffer-create 'gdb-inferior-io)
    (comint-output-filter proc string)))
(ad-activate 'gdb-inferior-filter)

This effectively replaces this function as defined in gdb-mi.el and removes the branch that calls gdb-display-buffer, which is the cause of the window thievery.

Prokofiev

Answer 4

You should use Sticky Windows to make your windows and buffers stick where they are but Sticky Windows won't stop gud/pdb from trying to steal your windows. When gud/pdb can't steal your source code window, it opens a new Emacs Frame even if there is another window on the current frame.

This comes from the fact that the function that tries to jump to the gud-pdb buffer (py-pdbtrack-track-stack-file) calls function pop-to-buffer with argument OTHER-WINDOW set to t.

To circumvent this behavior for all libraries that calls pop-to-buffer, you could cancel the role of OTHER-WINDOW by defining an advice on pop-to-buffer (in your .emacs) :

(defadvice pop-to-buffer (before cancel-other-window first)
  (ad-set-arg 1 nil))

(ad-activate 'pop-to-buffer)

You should also customize variable pop-up-windows to nil in order to force display-buffer (the low-level routine used to display a particular buffer on windows and frames) to not create a new window.

Retraction

Note that the arguments to pop-to-buffer have changed in Emacs 24, and that advice causes some havoc – Matriculate