bug#30151: Debugger API

[James Nguyen <james@jojojames.com>]

Thanks, I've submitted an issue here -> https://github.com/realgud/realgud/issues/206.

Looking at some old code I did when adding breakpoints for lldb, it looks like I just used the marker-filter and matched against strings in the filter looking for 'breakpoint print' strings and extracting the info out after.

That might be similar to how something like flymake/flycheck runs a *something* in a separate process and then matches strings against the output to get the error output out.

E.g. http://ix.io/EsZ (meant just for discussion)

I'm not sure how we can better support this flow (or if it's even a good idea) but from what I've seen the marker-filter is the one place where we can 'extract' information from the underlying debugger (using its output).

-- 
  James Nguyen
  james@jojojames.com

On Fri, Jan 19, 2018, at 2:19 AM, Eli Zaretskii wrote:
> > From: James Nguyen <james@jojojames.com>
> > Cc: 30151@debbugs.gnu.org
> > Date: Fri, 19 Jan 2018 01:25:47 -0800
> > 
> > Ideally, it'd be nice to have something simple that asks me:
> > 1. Where to draw breakpoints in the buffer.
> > 2. What locals exist and displaying them in some kind of 'locals' buffer.
> > 3. Maybe an extra window that will display extraneous information (similar to jdibug's stacktrace buffer)
> > 4. I'm missing some other common functionalities between debuggers.
> > 
> > I think some/all of ^ is very similar to gdb-many-windows but I've only ever seen that for *just* gdb.
> 
> I agree, but as I said, these capabilities need to be supported by the
> underlying debuggers.  Currently, only gdb-mi.el provides them because
> GDB includes a special interface for debugging front-ends, and that
> interface provides the functionality required for the features shown
> in gdb-many-windows.  If other debuggers can support similar
> functionalities, gud.el could be extended to do that for them as well.
> 
> Perhaps the first step would be to look at what realgud does to
> provide these features.  But please be aware that if you are going to
> read realgud's source with the intent of doing something similar in
> Emacs, you are advised to check with realgud's developers whether they
> will be willing to sign legal paperwork, in case you end up copying
> some of their code.
> 
> Thanks.