5

When using gdb -i=mi to debug a program, I typically split the window into two buffers vertically. But every time my program prints something gud automatically replaces my source code buffer with I/O buffer and pops up a new "frame" that contains my source code, and what's worse is that it creates a "dedicated window" that I can't switch back to source code. This behavior is obviously very very annoying, it should for example, open a new frame for the I/O buffer instead. How can I achieve that or just simply turn off auto replacing buffer for gud? (gud-gdb doesn't seem to have such behaviors but it doesn't show where breakpoints are)

  • I disabled (by commenting out) all references to setting a window dedicated with a t, and I removed/replaced the ACTION argument for display-buffer within gud-display-line to nil. I'm sorry that I don't have a fancy advice and I realize that is blasphemy to modify the source code. I set gdb-display-buffer-other-frame-action to my own custom function '(my-custom-function), but I'm presently not using that feature. I essentially wanted just two windows -- one window with the gdb debugger, and the other window gets the source-code. – lawlist Dec 3 '17 at 4:01
  • blasphemy continued: Within gdb-display-buffer, I commented out (set-window-dedicated-p window t). Within gdb-set-window-buffer, I commented out (set-window-dedicated-p window t). Then, I typed: M-x byte-compile-file. You could also create new functions instead and use things like defalias to replace your new function, or you could just require the source-code libraries in your init.el or .emacs before redefining the functions using the same name. I think the author liked having many windows and frames instead of just 2 windows on the selected frame. – lawlist Dec 3 '17 at 4:15
  • With regards to showing breakpoints, the code includes visual indicators in the fringe identifying the breakpoints. However, I haven't used those features yet. Today, is coincidentally the first time I have used these libraries and spent quite a bit of time implementing my own bug-fixes and setting up my desired behavior. If after you resolve the window display issue and you still don't see the breakpoints indicated with fringe indicators in the source-code buffer, then please consider posting a new question on that specific issue and try M-x eval-expression RET (display-images-p) RET. – lawlist Dec 3 '17 at 4:30
1

The automatic pop-up of the i/o buffer can be disabled by setting gdb-display-io-nopopup to t. In your .emacs file, add:

;; Prevent gdb from popping i/o window to the foreground on every output op
(setq-default gdb-display-io-nopopup t)

I learned this from ajp's answer here.

  • Can you add a snippet that should be added to the init file to make your answer easier to follow for novices? – DoMiNeLa10 May 2 at 19:29
  • That does work. How come none of us involved in this question didn't know that answer existed! – Mingheng Wang May 3 at 5:56
  • 1
    @DoMiNeLa10: Done. – Pablo Halpern May 10 at 18:39
  • @MinghengWang: I wish I knew. I've been struggling with this problem for years before I stumbled on ajp's answer after the nth search. – Pablo Halpern May 10 at 18:41
0

A partial answer is to disable gud from making the windows "dedicated", so you can change their buffer. From https://www.emacswiki.org/emacs/GDB-MI:

;; Force gdb-mi to not dedicate any windows
(advice-add 'gdb-display-buffer
        :around (lambda (orig-fun &rest r)
              (let ((window (apply orig-fun r)))
            (set-window-dedicated-p window nil)
            window)))

(advice-add 'gdb-set-window-buffer
        :around (lambda (orig-fun name &optional ignore-dedicated window)
              (funcall orig-fun name ignore-dedicated window)
              (set-window-dedicated-p window nil)))

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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