So, the layout itself is hardcoded (as mentioned in the documentation of the gdb function). This layout is defined in gdb-setup-windows
But then, since it's defined only in gdb-setup-windows, and that function is called whenever restoring that layout is needed... All you have to do is to override that function to make it generate the layout you fancy !
Unless some thing has changed with newer versions of MatLab, short answer is you cannot (MaTLaB 2011b here). Eric Ludlam, maintainer of matlab-emacs, does say so here in the matlab-emacs mailing list. MatLab lost an undocumented API which allowed it to show icons for breakpoints with select versions of GUD.
Emacs does generally use C-p and C-n for moving the cursor up and down, <up> and <down> are usually bound to the same command. That's why you get the unfamiliar behaviour of the arrow keys not cycling the history. As a compromise M-p and M-n are bound in these contexts to history cycling commands. The only exception I'm aware of would be term-...
This works for me using C-c C-c
Current directory is /src/build/emacs-24.5/src/
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
Starting program: /src/build/emacs-24.5/src/emacs
[Thread debugging using libthread_db enabled]
[New Thread 0xb4bffb40 (LWP 735)]
C-c C-c(gdb) break ...
After googling around and tweaking the code snippets from the internet, I got this solution and it works as expected:
'(gud-mode comint-mode gdb-locals-mode gdb-frames-mode gdb-breakpoints-mode)
"A list of modes when using gdb")
(defun kill-all-gud-buffers ()
"Kill all gud buffers including Debugger, Locals, Frames, Breakpoints.
I'm having similar issue with 24.5.1 which comes with Ubuntu 16 LTS.
Seems to be somehow related to this issue and using "gud-gdb" command as suggested in an answer to revert to the old GUD behavior solved my problem.
And within that issue, another answer describes the issue of the usage of "dedicated window" with new GUD in more details.
If you set the variable gud-find-file to a function, GUD will call it with any paths it gets from the debugger. My setup is something like this:
(let* ((name (replace-regexp-in-string "^/var/app" "." name))
(name (replace-regexp-in-string "^.*/lib/" ".ve/lib/" name)))
If thats indeed gdb-many-windows problem. One can avoid using gdb-many-windows and define similar functionality inside the function gdb-get-source-file. You can modify the source file and build from source, but can also defadvice gdb-get-source-file, e.g.
(defadvice gdb-get-source-file (after new-setup-gdb-windows activate)
This is the solution I came up with using hl-line. I needed to advise the function that updates the disassembly buffer and invoke hl-line-highlight directly to make it work.
(after nispio/ad-after-disas-handler-hl-line activate)
"Make sure that `hl-line' gets updated after updating disassembly buffer"
Thanks to @lawlist nudging me into the source code, I found out that gdb mode will highlight the line for me, but only on the condition that the window containing the disassembly does not have fringes. The following was enough to make that happen:
;; Enable automatic highlighting of the active line in disassembly window
(defun nispio/disable-window-fringes (...
There's nothing you can do with Emacs that will change how this works, since you're just asking Emacs to ask gdb to step. Try compiling your program with -Og -ggdb, to ensure that you have the maximum amount of debugging information available.
And of course there are about a billion related options that you can use to control the amount of optimization the ...
The right place is gud-minor-mode-map.
I have got the following bindings in my setup. Pick whatever suits you for your setup.
(defun gdbTZA-gud-run-or-cont (arg)
"Combination of `gud-run' and `gud-cont'.
If the debugged program is already running use `gdb-cont' and use `gdb-run' otherwise."
(if (assoc-string gdb-inferior-status '("...
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.
I also had problems with gdb-many-windows. My window and buffer setup was always messed after certain events. I decided to rewrite it myself, so I can also customize my window setup better. You have to take a look at the relations between gdb-many-windows, gdb-restore-windows and gdb-setup-windows.
If you only want to fix your problem with the source file, ...
I'm not sure if this will help, but realgud doesn't have to use comint (although it can). It also works inside eshell. For use with gdb, You have to run "set annotate 1" to get it to track source-code lines, after running "M-x set-track-mode".
realgud is available from Melpa. At some point it will be in GNU Emacs Elpa.
M-x gud-gdb is fine when debugging on emacs24, this works on gdb6+
M-x gdb requires gdb7+
when debugging, you need compile your program with gcc -g -O0. I use M-x gud-gdb on both Mac/Linux without issue.
Alas, I don't think this will be easily doable if at all. gud with gdb works a little differently (and, overall, better) than the other debuggers gud supports because it has a more tighter communication with the underlying debugger, gdb.
For the other debuggers, I think what you'd have to do is first see if there is a gud process running. If so, then try ...
However, realgud is lacking documentation,
Although I largely agree, there is a wiki How-to-Use which anyone can contribute to. And I suppose you can open an issue to get help.
By the way, why gud with pdb does not have the function gud-until?
pdb does have an until command. Although when I tried it outside of a function it seemed to not work, I ...