Re: Executing Emacs commands when a gdb breakpoint is hit

[otadmor .]

See example in
https://github.com/otadmor/emacs-conf/blob/master/gdb.gif

On Fri, Jan 24, 2020 at 10:01 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Skip Montanaro <skip.montanaro@gmail.com>
> > Date: Thu, 23 Jan 2020 15:00:16 -0600
> > Cc: Help GNU Emacs <help-gnu-emacs@gnu.org>
> >
> >  But in general, I must admit I find this design somewhat strange.  GDB
> >  offers you 3 extension languages: the CLI scripting, Python, and Guile
> >  Scheme.  Why not use one of these to do what you want? this is how the
> >  GDB developers intended for you to extend the debugger for doing these
> >  kinds of jobs.  If you use Guile, you could even write code that is
> >  almost Emacs Lisp ;-)
> >
> > Note that I'm not really trying to script GDB. I'm trying to adjust the 
> > display in Emacs of the file which is being
> > compiled. It seems to me that the proper language for that is ELisp.
>
> Emacs displays stuff by following the responses from GDB.  So
> injecting such responses (by scripting GDB) will eventually allow you
> to solve your problem, either entirely in the scripting commands, or
> if customizing what Emacs does via the existing hooks.
>
> My point is that you shouldn't ask yourself "how do I run an Emacs
> function when a breakpoint is hit", because there's no way of doing
> that.  This question encourages the line of thinking that leads you to
> write code that cannot work well, because this line of thinking is
> based on incorrect assumptions.
>
> > If I had (for
> > example) two different stop functions in my list (I don't currently), it's 
> > not clear how I'd guarantee the two
> > functions didn't step on one anothers' toes.
>
> The hook function receives the parsed MI response as its argument, so
> each function can decide whether it does anything in each case.
>


-- 
Gretz,
Ofir Tadmor

ICQ: 77685691
Mail: otadmor@gmail.com