realgud/realgud

The Grand "Cathedral" Debugger rewrite

An extensible, modular GNU Emacs front-end for interacting with external debuggers, brought to you by Rocky Bernstein (@rocky) and Clément Pit-Claudel (@cpitclaudel).

Setup

You can install RealGUD from MELPA, a repository of Emacs packages. If you don't have MELPA set up, add the following to your .emacs and restart Emacs:

(require 'package)
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
(package-initialize)

You can then run the following commands to install RealGUD:

M-x package-refresh-contents RET      (to refresh your package database)
M-x package-install RET realgud RET   (to install and compile `realgud` and its dependencies)

Alternatively, you can install RealGUD using el-get or from source directly. See this article in our wiki for more info.

Quick start

Use M-x load-library RET realgud RET to load RealGUD.

Launching the debugger

Open a source file, then use M-x realgud:<debugger-name> to start your favorite debugger (for example, you can use M-x realgud:pdb to launch PDB, a Python debugger). RealGUD opens two windows: the command window (showing the debugger's REPL), and the source window, showing your code (with some debuggers, such as realgud:gdb, this window does not appear until you type start in the command window). An solid arrow ▶ indicates the current line in the source window. Grayed out arrows indicate previous positions.

Using the debugger

All usual debugger commands work in the command window: for example, you can type n RET in the command window to step forward one source line. But RealGUD's power lies in the source window: in it, most single keys correspond to a debugger action. For example, you can press n in the source window to step forward.

Source window commands

Here is a quick rundown of the most useful commands. “🐁” indicates mouse commands (commands that can be run by clicking on a variable or in the margins). Many of the commands are accessible from the tool bar (tool-bar-mode) and the menu (menu-bar-mode).

• Motion commands

  Command	Action
  n, F10	Next (aka “step over”, “step through”)
  s, SPC, F11	Step (aka “step into”)
  f, S-F11	Finish (aka “step out”, “return”)
  c, F5	Continue (run to next break point)

• Using breakpoints

  Command	Action
  b, F9	Set breakpoint 🐁
  D	Clear breakpoint 🐁 (by number)

• Inspecting variables

  Command	Action
  mouse-2 (middle button)	Inspect variable under cursor (in tooltip) 🐁
  e	Evaluate expression

• Control commands

  Command	Action
  q, S-F5	Quit
  R, r	Run (aka “restart”)
  S	Go to command window

Supported debuggers

RealGUD supports many external debuggers. Help us support even more!

Advanced topics

Extra commands

“⚙” indicates a work-in-progress (contributions welcome!)

Command	Action
U	Until (run to a greater source line)
u, >	Up stack (move to older stack frame)
d, <	Down stack (move to younger stack frame)
X	Clear breakpoint (by line)
j	Jump to current line ⚙
-	Disable breakpoint ⚙
+	Enable breakpoint ⚙

Tracking an existing debugger process

Use M-x realgud-track-mode inside an existing shell, or eshell buffer to track an already-running debugger process.

RealGUD's wiki

Browse the wiki for more information about setting up, using realgud, exploring features, and lots more.

realgud's Issues

Error: Cannot open load file: load-relative

I try install realgud from MELPA:

realgud Version: 20131213.1213

but during compiling I get a lot of errors like:

Compiling file /home/user/.emacs.d/elpa/realgud-20131213.1213/realgud/common/backtrace-mode.el at Fri Dec 20 00:46:34 2013
Entering directory `/home/user/.emacs.d/elpa/realgud-20131213.1213/realgud/common/'
backtrace-mode.el:3:1:Error: Cannot open load file: load-relative

Short-key commands in source buffers switch to the command window after each command

This seems to only happen when I have the active frame split into two windows--the source window and the command window. If I use short-key commands without an active command window in the active frame, the active window is not changed.

I think it may be related to realgud-window-cmd-undisturb-src, but for some reason I am having trouble reproducing this in edebug. I've had this happen in trepan2 and in pdb, but haven't tried any other debuggers yet.

Document the install script

What will the make install invocations do?

The script is asking for my password, so I'm assuming they're going to write into system directories. Why?

Invoking realgud:gdb without command line arguments does not work

Invoking realgud:gdb without command line arguments should either:

a) work
b) give some meaningful error message

At the moment, it gives a "Wrong type argument: stringp, nil" error.

realgud:cmdbuf-associate promprt should filtering on command buffers

Right now realgud:cmdbuf-associate uses the current buffer when it prompts for a buffer to associate to. It should prompt using the list of current realgud cmd buffers.

Clearing breakpoints in realgud:gdb is not reflected in the UI

I use the function realgud:gdb-pid-associate to debug a process using a PID. Afterwards setting and clearing breakpoints works fine now. The red dots, which indicate the break points, are not cleared after realgud:cmd-clear.

Procedure:
M-x realgud:gdb-pid-associate 4196 RET
Switch to source buffer via C-x b ...
M-x realgud:cmd-break
On the screen a red dot appears
M-x realgud:cmd-clear
The red dot stays on the screen

Expectation: The red dot goes away.

Best regards,
Kilian.

Using gdb with "-p <pid>" option, creates new buffer with name <pid>

Procedure:
M-x realgud:gdb
gdb -p 4346

C-x b TAB
Two new buffers: 4346 and gdb 4346 shell

I expect only one new buffer gdb 4346 shell.

Regards,
Kilian.

additional line in realgud-pkg.el breaking melpa build

MELPA is expecting the first line of the -pkg.el file to be define-package which I believe to be in line with what package.el expects.

see melpa/melpa#869

any specific reason for that define-function?

Byebug support for Ruby

I'm interested in using emacs-dbgr with the byebug debugger for Ruby. Byebug is newer and has better support for Ruby 2+.

I will probably try doing this myself in the next couple of days. Looks related to #39.

Breakpoint circle in margin gets overwritten by line numbering

I use linum-relative (https://github.com/coldnew/linum-relative) to display cursor-relative line numbers that update every time the cursor moves. Since this also uses the left margin when I move my cursor the red circle marker gets blown away. It'd be nice if the circle would be displayed before/after the number so I can have all the info on the left side. Offering a customization option to put the marker in the right margin could technically work but source code tends to be biased to the left side of the screen.

Document (if possible) attaching already open buffers to debugger sessions

I have several buffers (python modules) opened I wish to attach to a debugger. I run pdb bin/script and then I need to place breakpoints on those opened buffers. How do I proceed? Is this possible?

See http://stackoverflow.com/questions/21443801/how-to-attach-an-existing-buffer-to-a-realgud-debugger

File name completion in "Run XXX (like this):" minibuffer prompt

For M-x gdb, I can complete the file name of the executable to run in the minibuffer with TAB. It would be nice if the same worked for the various M-x realgud:xxx commands.

run dbgr-rdebug, can not auto fetch current buffer name.

When I first use dbgr-rdebug, it auto get current buffer file name as rdebug argument.

e.g. current buffer file name is1.rb
it tips:

Run rdebug (like this): rdebug /root/bin/rails/1.rb

But when I want to debug another files , example: /root/ruby/2.rb

It still point to previous file-name, it not convenient.

I think, it ought to always fetch current buffer file name.

I installed using git script.. but now load-library does not show any rdbg

output excerpts

Making install in trepanx
make[4]: Nothing to be done for `install-exec-am'.
 /usr/bin/install -c -m 644 'core.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/core.el'
 /usr/bin/install -c -m 644 'core.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/core.elc'
 /usr/bin/install -c -m 644 'init.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/init.el'
 /usr/bin/install -c -m 644 'init.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/init.elc'
 /usr/bin/install -c -m 644 'track-mode.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/track-mode.el'
 /usr/bin/install -c -m 644 'track-mode.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/track-mode.elc'
 /usr/bin/install -c -m 644 'trepanx.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/trepanx.el'
 /usr/bin/install -c -m 644 'trepanx.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepanx/trepanx.elc'
Making install in trepan8
make[4]: Nothing to be done for `install-exec-am'.
 /usr/bin/install -c -m 644 'core.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/core.el'
 /usr/bin/install -c -m 644 'core.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/core.elc'
 /usr/bin/install -c -m 644 'init.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/init.el'
 /usr/bin/install -c -m 644 'init.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/init.elc'
 /usr/bin/install -c -m 644 'track-mode.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/track-mode.el'
 /usr/bin/install -c -m 644 'track-mode.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/track-mode.elc'
 /usr/bin/install -c -m 644 'trepan8.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/trepan8.el'
 /usr/bin/install -c -m 644 'trepan8.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/trepan8/trepan8.elc'
Making install in zshdb
make[4]: Nothing to be done for `install-exec-am'.
 /usr/bin/install -c -m 644 'core.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/core.el'
 /usr/bin/install -c -m 644 'core.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/core.elc'
 /usr/bin/install -c -m 644 'init.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/init.el'
 /usr/bin/install -c -m 644 'init.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/init.elc'
 /usr/bin/install -c -m 644 'track-mode.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/track-mode.el'
 /usr/bin/install -c -m 644 'track-mode.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/track-mode.elc'
 /usr/bin/install -c -m 644 'zshdb.el' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/zshdb.el'
 /usr/bin/install -c -m 644 'zshdb.elc' '/usr/local/share/emacs/site-lisp/dbgr/debugger/zshdb/zshdb.elc'
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in lang
make[3]: Nothing to be done for `install-exec-am'.
 /usr/bin/install -c -m 644 'perl.el' '/usr/local/share/emacs/site-lisp/dbgr/lang/perl.el'
 /usr/bin/install -c -m 644 'perl.elc' '/usr/local/share/emacs/site-lisp/dbgr/lang/perl.elc'
 /usr/bin/install -c -m 644 'posix-shell.el' '/usr/local/share/emacs/site-lisp/dbgr/lang/posix-shell.el'
 /usr/bin/install -c -m 644 'posix-shell.elc' '/usr/local/share/emacs/site-lisp/dbgr/lang/posix-shell.elc'
 /usr/bin/install -c -m 644 'python.el' '/usr/local/share/emacs/site-lisp/dbgr/lang/python.el'
 /usr/bin/install -c -m 644 'python.elc' '/usr/local/share/emacs/site-lisp/dbgr/lang/python.elc'
 /usr/bin/install -c -m 644 'ruby.el' '/usr/local/share/emacs/site-lisp/dbgr/lang/ruby.el'
¯ /usr/bin/install -c -m 644 'ruby.elc' '/usr/local/share/emacs/site-lisp/dbgr/lang/ruby.elc'

But now I start Emacs and run load-library .. it does not show me rdbg

Hi, Why new version not the Break-point view ?

Hi, old version , when I run dbgr-rdebug, it load dbgr in a new windows,
the same time, the original code window is visible.

I can step the rdebug, and look my code..

But, now change to a full-screen dbgr comint-shell, where is my code window ?

realgud only has command buffer

I installed the elpa package and invoked realgud:gdb. I got a command buffer, but that's it. I don't see anything different from what I would get manually invoking GDB inside a shell, and there's nothing in the documentation saying I should need to do more. I can manually type in the command to set a breakpoint, which works, and I see the extra output from annotate being set to one, but when I run and hit the breakpoint no window pops up with the source file on the line of the breakpoint like I would normally get with gud. Am I doing something wrong?

error in mac os x

use install script in Mac os x 10.8.2, build error

In toplevel form:
reset.el:5:1:Error: Symbol's value as variable is void: dbgr-loc-pat
make[3]: *** [reset.elc] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
--- make exit status is 0

Compiling from melpa fails in require-relative-list

I tried to install realgud 20150719.1657 from melpa (NOT melpa-stable).
On I got a bunch of errors in the Compile-Log:

Compiling file c:/my/.emacs.d/elpa/realgud-20150719.1657/realgud.el at Thu Jul 30 08:48:17 2015
Entering directory c:/my/.emacs.d/elpa/realgud-20150719.1657/
realgud.el:105:1:Error: Cannot open load file: no such file or directory, c:/Emacs/share/emacs/24.5/lisp/progmodes/realgud/common/track-mode
Leaving directory c:/my/.emacs.d/elpa/realgud-20150719.1657/

In my case, that file is in ~/.emacs.d/elpa/realgud-20150719.1657/realgud/common/track-mode.el.
If it's require-relative-list, why doesn't it look in the local dir but in c:/Emacs/share/emacs/24.5/lisp/progmodes/ ?

realgud-populate-common-fn-keys-standard is always run

I wanted to disable the standard fn keys bindings.
The function realgud-populate-common-fn-keys-standard is always run independent of the settings of the realgud-populate-common-fn-keys-function variable. It is executed right after the ifclause in the realgud-populate-common-keys function.

I ended up investigating this due to wanting to prevent realgud from defining f5 which I use for other stuff. There I also found a minor typo, since in realgud-populate-common-fn-keys-standard the f5 key is bound to realgud-continue which should be realgud:cmd-continue.

Thanks a lot for providing such a useful package!

how to use realgud with gdb

Hi.
I've just installed it through melpa and decided to try.

My question: how to set breakpoint at non-associated source file.

What I did so far:

M-x realgud:gdb: gdb myBinary
(gdb) // this buffer is called command buffer.
(gdb) run
(gdb) C-c C-C // stop the debugged process
(gdb) up/down /// as expected, source buffers will we displayed. These source buffers will automatically be associated to command buffer.
M-x find-file: some file with source code.
This file is NOT associated to command buffer, I need to do it locally.
M-x realgud:cmdbuf-associate #. I don't think it associates current buffer. Why? because Debugger menu entry does not allow to set any breakpoints afterwards.

regards

Cannot start realgud:gdb "file-name-base: Wrong type argument: stringp, nil"

I just installed realgud via MELPA on Emacs 24.4, and tried to run it via M-x realgud:gdb. I get this error message in the minibuffer:

file-name-base: Wrong type argument: stringp, nil

Sadly, the documentation is very lacking, so I don't even know if I hit the right entry point.

My use case is that I want to launch a gdb process and attach to a running process via PID. So maybe I am using it wrong?

Not possible to connect to pdb debugger started via non-'pdb' command

Celery and several other threaded applications make pdb style debugging available over telnet/sockets (see: http://celery.readthedocs.org/en/latest/tutorials/debugging.html)

gud.el currently supports connecting to these by changing the command run from pdb /path/to/file.py to telnet localhost 6900

this crashes because localhost is expanded by pdb-parse-cmd-args. Is this fixable, and/or is there a reasonable workaround?

Support Haskell's ghci debugger

Here are the commands: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ghci-debugger.html

Duplicate menu items in "Complete" "In/Out" and "Signals"

Cannot invoke gdb

Hi,

when trying to use realgud with gdb, it can't start gdb, saying "Error running command: gdb". I have gdb installed and the normal gdb mode via "M-x gdb" runs fine. It doesn't matter if I enter a full path or just "gdb" in the command line.

I tested on two different computers with emacs 24.5 and emacs 25.0.50.

What am I doing wrong?

Best regards,
Kilian.

Restarting debugger in an old command buffer brings back breakpoints

When a command buffer reused in future debugger invocation. The string of previous invocations are parsed and we see breakpoints that aren't there. Fix this up by eliminating realgud's use of comint-last-input-end and comint-last-input-start and put this into the cmdbuf-info structure. This is probably a good thing anyway as it reduces the comint dependency and one less global variable.

pry-debugger support?

It's a bit nicer to use than rdebug and debugger.

The commands are the same, but realgud-track-mode doesn't work (after I choose rdebug in the prompt), so some tweaking, or maybe generalizing, will be required.

if: Can’t find a process for buffer

M-x realgud:nodejs

Current directory: /Users/codefalling/code/cleanjs/
Command: node debug /Users/codefalling/code/cleanjs/main.js localhost:5858
debug> connecting to 127.0.0.1:5858 ..< Debugger listening on port 5858
debug> . ok
debug> break in main.js:1

Then I try M-x nodejs-track-mode in my main.js.I got if: Can’t find a process for buffer.

el-get-install failed

MacOSX:
M-x el-get-install realgud

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I .
autom4te: need GNU m4 1.4 or later: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/m4
aclocal: error: /usr/local/Cellar/autoconf/2.69/bin/autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

Set breakpoint from source automatically if only one debug session?

If I understand correctly, the reason a breakpoint cannot be set in a source buffer without it first being associated with a command buffer is because their might be more than one debugging session.

When there is only one debug session, what about having the ability to set a breakpoint in a source buffer and having it be auto-assigned to the sole command buffer? If there is more than one, then print an error message or even have the user choose one of the existing sessions. This could even be extended to multiple sessions based on the source buffer's major mode - if there is only one node debug session then all *.js files would be auto-assigned to it but C files would be assigned to the C/C++ debug session.

I'm sure having multiple debugging sessions is crucial in some situations, but I'd guess that having a single one at a time is extremely common. The convenience of being able to use emacs as a source debugger without the extra complication of dealing with the associations would be fantastic.

Expansion of file name via %X is not working in realgud:gdb

I start realgud:gdb with attaching to a process id and automatically assigning the source buffers, via the following code snippet (using -filter from dash.el):

(defun my-find-command-buffer (pid)  
  "Find the current command buffers for the given pid."
  (-filter (lambda (buf)
             (and
              (string-prefix-p (concat "*gdb " (number-to-string pid)) (buffer-name buf))
              (get-buffer-process buf))) (buffer-list)))

(defun my-start-debugging-pid (pid)
  "Start debugging process with pid PID."
  (interactive "nEnter the pid: ")
  (let* ((cW (selected-window)))
    (if (one-window-p)
        (select-window (split-window-horizontally))
      (other-window 1))
    (realgud:gdb (concat realgud:gdb-command-name " -p " (number-to-string pid)))
    (select-window cW)
    (mapc (lambda (buf)
            (realgud:cmdbuf-associate (buffer-name buf))) (my-find-command-buffer pid))))`

This works great. Afterwards setting and removing breakpoints via realgud:cmd-break and realgud:cmd-clear does not work, because the file name (seems to be %X in the source code) is not expanded and only the line number is given to gdb.

Defining realgud:cmd-break like follows:

(defun my-realgud:cmd-break()
  "Set a breakpoint at the current line"
  (interactive)
  (realgud-send-command (concat "break " (buffer-file-name) ":"
                                (number-to-string (line-number-at-pos)))))

does work (similar for clear), but the breakpoint is then not cleared from the UI anymore (of course).

Why is the %X not expanded?

Consider tagging a release

This looks like a really fantastic project.

If it is relatively stable, please consider tagging a MELPA-compatible release. This will make realgud available to those of us using MELPA stable.

Can't use real-track-mode?

So in a shell-mode shell I start gdb, then I try to run real-track-mode and tell it 'gdb' for the name. The 'Debugger' menu options appear, but when I try to actually choose any of them they don't work, giving the message "if: Command buffer doesn't think a debugger is running". I have "set annotate 1" in my .gdbinit, and I have normal (gdb) prompt displaying, so why wouldn't real-track-mode think the debugger is running? Looking in command.el it looks like it checks of some vars are bound, but I'm not sure when they should have been set. Am I right in thinking it's intended this should Just Work (TM)?

Can you set a breakpoint in the source buffer to debug Node.js?

1. Is there a way to circumvent having to place a debugger; statement in my source code to trigger the initial break to debug?
2. How can I set a breakpoint in the source buffer?

I have done the following so far:
I started my Node.js server as node --debug app.js in my terminal and connected to it in Emacs like so:
load-library
realgud
realgud:nodejs
Run node (like this): node debug localhost:5858
I then get the message I Don't have node listed as a debugger. in the minibuffer and successfully connect with an output debug> connecting... ok in the command buffer.

I have a debugger; statement in my source code to break, but was wondering if it was possible not to have to use it.
Issuing realgud:nodejs-set-break in the source-buffer gives me the message Can't find process for command buffer <my_file_name_here.js> in the minibuffer.

I tried digging around for some answers but came up a little short.

Invalid image type `xpm'

when installing emacs-dbgr with the shell script for a non-gui emacs I get

In toplevel form:
backtrack-mode.el:11:1:Error: Invalid image type `xpm'
Wrote /Users/vvolle/workspaces/net/emacs-bash-dbgr/emacs-dbgr/dbgr/common/bp.elc

In end of data:
cmds.el:185:1:Warning: the function `dbgr-terminate-srcbuf' is not known to be
defined.
Wrote /Users/vvolle/workspaces/net/emacs-bash-dbgr/emacs-dbgr/dbgr/common/cmds.elc

(I had replaced the Emacs to a Gui-Emacs and just reverted to the non-Gui Emacs for testing
after rocky/emacs-loc-changes#1). Will go back to the Gui Emacs)
I am not sure that it is necessary to support a non-Gui Emacs

Using w/ llvm/clang's lldb?

You know of any support for this? I don't want to write one if I don't have to.

NodeJs setting breakpoints uses full paths

The node debugger doesn't understand full paths when setting breakpoints while realgud:nodejs-set-break sends absolute paths. This issue is addressed at the node repository since I think it would be better that this is solved on their side, but they seem to have neglected it so if there is a way to fix it on the realgud side that would be nice aswell.

Build failed on CentOS and Cygwin

Update: Exactly same error on CentOS 6.4

I'm using Emacs 23.1.1 on CentOS 6.4 and Emacs 24.3.1 on Cygwin.
I build failed from MELPA and Git:

From MELPA

Open Emacs and run:

M-x package-refresh
M-x package-install realgud

It shows:

Compiling file /home/carl/.emacs.d/elpa/realgud-20130824.2059/realgud.el at Wed Nov 13 14:36:30 2013
realgud.el:86:1:Error: Cannot open load file: load-relative
Leaving directory `/home/carl/.emacs.d/elpa/realgud-20130824.2059/'

From Git

In Mintty run:

SUDO_CMD=' ' bash < <( curl https://raw.github.com/rocky/emacs-dbgr/master/install-from-git.sh )

It shows:

checking for emacs... /usr/bin/emacs
configure: "Checking emacs version and prerequiste packages"
Cannot open load file: loc-changes
configure: error: Can't continue until above error is corrected.
--- /bin/zsh ./autogen.sh exit status is 0

Error with realgud:gdb in Emacs 24.4.50

This is the error:

realgud:gdb track-mode-hook called
let_: Attempt to set a constant symbol: nil
Display doesn't support breakpoint images in fringe
error in process filter: let_: Symbol's value as variable is void: gdb-short-key-mode-map
error in process filter: Symbol's value as variable is void: gdb-short-key-mode-map

My Emacs version: GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2014-08-11 on xtuudoo-Satellite-L640

Add this to melpa?

I think it would be great if this was added to melpa. Right now it's a bit of a pain to install, especially given the dependencies. You can decide if you want to vendor the dependencies, or add them to melpa too and let the package manage install them. I think at least your testing framework would do well in Melpa.

JDB: too many arguments passed to realgud:run-process

in jdb.el, 6 arguments are being passed to realgud:run-process, but in run.el, realgud:run-process is written to only accept a maximum of 5. This causes an error when trying to use realgun:jdb.

https://github.com/rocky/emacs-dbgr/blob/master/realgud/debugger/jdb/jdb.el#L87-L89

Using gdb with "-p <pid>" option, creates new buffer with name <pid>

When invoking realgud:gdb with command "-p pid", where "pid" is a process id, a new empty buffer with name "pid" is created.

realgud:tooltip-eval breaks realgud-track-mode

The command works, but the tracking immediately stops after it. I can press s or SPC to step, this is reflected in the comint buffer, but the source buffer remains stuck (the line indicator stays in the same place).

Using debugger with rdebug integration.

Tooltip mode

GUD has a tooltip mode where it shows symbol values as a tooltip on mouse hover. It would be nice to have the same in realgud (e.g. in the Python debugger mode).

Invoke GDB indirectly via shell script

Hey,

I have created a shell script which does a bit houskeeping and invokes at the end GDB. The problem is I can't call this script like M-x realgud:gdb RET script_name.sh RET as realgud complains that it can't find the command buffer for buffer XYZ.

What works, is calling the script from eshell or shell (emacs), that's all, no other windows are shown, nor is the function gdb-many-windows available.

Thanks for your help!
Chris

realgud:gdb command to automatically associate buffers

If gdb is running "info files" will tell you files associated with the session. Use that to match up Emacs buffers.

if step into a library and non-normal exit, dbgr-redebug can not used.

if step into a library and non-normal exit, dbgr-redebug can not used.

Error message:

Error running command: rdebug /root/bin/ruby/ruby/test.rb

When use Emacs server daemon, reopen buffer or frame,
still can not reinvoke dbgr-rdebug.

Must restart emacs sever to use it.

It seem to background have a ruby process, but dbgr can not attach it.
even kill that ruby process, run (dbgr-rebug) still error tips. and can not use.

docs: how to start gdb with realgud?

I managed to install realgud based on instructions on https://github.com/rocky/emacs-dbgr. The page is readable and easy to follow.

However, I don't see it mention how to actually start the debugger? What do I do after load-library'ing realgud?

I tried:

realgud-gdb
(gave it gdb ./a.out)

After that all I get is a message saying:

realgud-gdb track-mode-hook called
realgud-send-command: Command buffer doesn't think a debugger is running

I also tried giving "gdb -i=mi ./a.out" as the parameter for the gdb command line prompt.

The project looks promising and I might even contribute, but I'd like to give this stuff a try first. :)

MELPA package have no description.

In *Package* buffer there are string:

realgud            20140211.... installed  No description available.

I expect that instead of No description available we have more meaningful description.

Compiling realgud locally is not possible

I can byte-compile realgud via ./configure + make without problems when its dependencies (list-utils, etc.) are installed globally, e.g. in /usr/local/share/emacs/site-lisp.

But when they are not available globally, but locally in my init.el's load path, they are not found by the configure script.

Is this by design or is there some workaround for that?