[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Executing Emacs commands when a gdb breakpoint is hit

From: Eli Zaretskii
Subject: Re: Executing Emacs commands when a gdb breakpoint is hit
Date: Fri, 24 Jan 2020 10:01:29 +0200

> From: Skip Montanaro <address@hidden>
> Date: Thu, 23 Jan 2020 15:00:16 -0600
> Cc: Help GNU Emacs <address@hidden>
>  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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]