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)
Asked
Active
Viewed 1,456 times
5
-
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 03 '17 at 04: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 03 '17 at 04: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 03 '17 at 04:30
2 Answers
2
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.
Pablo Halpern
- 136
- 5
-
Can you add a snippet that should be added to the init file to make your answer easier to follow for novices? – May 02 '19 at 19:29
-
That does work. How come none of us involved in this question didn't know that answer existed! – Mingheng Wang May 03 '19 at 05:56
-
1
-
@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 '19 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)))
Chris
- 261
- 3
- 5