From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Executing Emacs commands when a gdb breakpoint is hit
Date: Fri, 24 Jan 2020 10:01:29 +0200 [thread overview]
Message-ID: <83ftg5s2p2.fsf@gnu.org> (raw)
In-Reply-To: <CANc-5Uw7oDFNw7u34p0NSQV9e+gwQZMN1FwbWbRkECHcf2v9CA@mail.gmail.com> (message from Skip Montanaro on Thu, 23 Jan 2020 15:00:16 -0600)
> 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.
next prev parent reply other threads:[~2020-01-24 8:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 18:02 Executing Emacs commands when a gdb breakpoint is hit Skip Montanaro
2020-01-21 18:39 ` Eli Zaretskii
2020-01-22 13:48 ` Skip Montanaro
2020-01-22 17:04 ` Eli Zaretskii
2020-01-22 19:55 ` otadmor .
2020-01-22 21:07 ` Skip Montanaro
2020-01-23 14:45 ` Eli Zaretskii
2020-01-23 21:00 ` Skip Montanaro
2020-01-24 8:01 ` Eli Zaretskii [this message]
2020-04-07 20:21 ` otadmor .
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ftg5s2p2.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).