How to attach a command buffer to current source buffer [draft]

custom-realgud.el

(when (and (require 'dash) (require 'realgud) (require 'grizzl))
   (defun xars-grizzl-select-cmdbuf()
      "Lets the user select a realgud command buffer, unless there's a single
command buffer, in which case returns the buffer directly."
      (interactive)
      (let ((cmdbuffers (-select #'realgud-cmdbuf? (buffer-list))))
	 (if (> (length cmdbuffers) 1)
	    (let* ((cmdbuffers-names (-map #'buffer-name cmdbuffers))
		   (cmdbuffers-index (grizzl-make-index cmdbuffers-names)))
	       (let ((selection (grizzl-completing-read
				   "Debugger Buffer: " cmdbuffers-index)))
		  (when selection
		     (message "Selected debugger %s" selection)
		     (get-buffer selection))))
	    ;; else (no buffer or a single one)
	    (car cmdbuffers))))

   (defun xars-attach-to-cmdbuf ()
      "Attaches current buffer to a debugging session."
      (interactive)
      (-when-let (cmdbuf (xars-grizzl-select-cmdbuf))
	 (message "Attaching current buffer %s to command buffer %s"
	    (current-buffer) cmdbuf)
	 (realgud-srcbuf-init-or-update (current-buffer) cmdbuf)))

This is not 100% working I have to figure out why yet...

Details are important. When I tried the above via (realgud-srcbuf-init (current-buffer) (xars-grizzl-select-cmdbuf) "trepan.pl" nil), the code above worked. One simple way to check in running M-x realgud-srcbuf-info-describe.

There are lots of other bugs lots of other places, such as in the code to set a breakpoint in "trepan.pl" and bugs in that debugger in reporting errors and so on. I could go down a rabbit-hole of fixing problems without possibly addressing yours.

So, do you think the above code is faulty? When I have a problem like this, here's what I do.

• Create a test case for the code above. See the emacs-dbgr/test directory for lots of examples for how to write some simple tests.
• Run (setq debug-on-error 't) and try again
• Look at *Messages*
• Look in the command buffer for error messages

I think i can reproduce the problem. The command buffer has a list of source buffers it knows about. So attaching a new one probably has to add it to that list. Gotta run but will look at later.

Commit realgud/realgud@9f56eba may improve things.

Hi @rocky, I'm not a guru ELisp developer. I have installed realgud via ELPA/MELPA.

I've just clone it, but the configure script is missing (or I'm missing something about how to install for development)

Why does realgub-srcbuf-init-or-update pass "unknown" to realgud-srcbuf-init as the debugger-name if we already have the debugger-name? Would that influence the outcome?

I've just find out another conceptual misconception I was having: I'm used to set breakpoints with PyDev even if the debugger is not "stopped" and the program is running (I work a lot with web apps: Pyramid, Django and lastly OpenERP over Werkzeug) so I comes natural to me to try to place a breakpoint while the web server is running. So when I say that "pdb does not honors my breakpoints", actually pdb was not actually receiving the "break" command.

Does trepan2 uses a kind of client/server architecture that would allow me to put breakpoints even is the program is running. Does anyone has made a pydev debugger for realgud?

I've just clone it, but the configure script is missing (or I'm missing something about how to install for development)

Autoreconf comes into play here to create a configure script. See https://github.com/rocky/emacs-dbgr/wiki/How-to-Install

Why does realgud-srcbuf-init-or-update pass "unknown" to realgud-srcbuf-init as the debugger-name if we already have the debugger-name? Would that influence the outcome?

Storing the debugger name and arguments was there just so that one could suggest the invocation one had previously used in the source buffer. But all this is hoaky and hacky. The history ring also has a list of invocations. And there is a command buffer around that has the last one used too. So with commit [67af15a] I have removed all of this.

trepan2 has a client/server architecture see out-of process debugging and the better remote debugging protocol where we don't have to parse strings like realgud does. But that said, I don't understand how PyDev can set a breakpoint in a running program short of doing something in a signal handler, or maybe the main thread somehow. Does it check that the place you want to breakpoint is valid? Does it give an acknowledgement that the breakpoint has been set?

No, there is no interface in emacs-dbgr for PyDev. https://github.com/rocky/emacs-dbgr/wiki/How-to-add-a-new-a-debugger describes how to add a new one for the simple sorts of debuggers of the kind currently supported. There still is too much cut and pasting which I'd like to remove.

In general there always has been much more work that needs to be done than people interested in doing it.

Hi @rocky,

It's been a long time... I think what PyDev does is to spawn two communicating processes (or threads):

A middleware and the debugger server.

The debugger runs the programs and has a trace function that can simply check a global state shared by both the middleware and the server.

The client actually communicates to the middleware that maintains the list of break points, state, etc...

When the clients sets a break, the middleware stores this setting. Later on the debugger process' trace function gets to this break and comunicates this to the middleware and the clients gets this.

This is just a guess about how to architecture such client/server debugger that can set breaks while the debugger is running.

I think that in order to accommodate such a debugger major changes are required in the core of realgud.