From: Stephen Berman <stephen.berman@gmx.net>
To: John Yates <john@yates-sheets.org>
Cc: help-gnu-emacs@gnu.org
Subject: Re: highlight current source line during debugging
Date: Tue, 05 Feb 2013 23:36:04 +0100 [thread overview]
Message-ID: <87ip66bd7v.fsf@rosalinde.fritz.box> (raw)
In-Reply-To: <CAJnXXoj8ZskKRkKkR96==O-_cFW8skwuGeA1pYcz-8fFCtCPqg@mail.gmail.com> (John Yates's message of "Tue, 5 Feb 2013 08:56:38 -0600")
On Tue, 5 Feb 2013 08:56:38 -0600 John Yates <john@yates-sheets.org> wrote:
> Thanks for this suggestion. To implement it seems to require that one
> know the name of the elisp function which places the overlay arrow. I
> have been having a hard time figuring this out for gdb disassembly
> buffers.
I'm not familiar with these, nor with the code for them, but glancing at
gdb-mi.el it looks like the overlay arrow is set in
gdb-disassembly-handler-custom, though I can't tell whether you can
advise this to get line highlighting. I also notice that gud.el appears
to provide support for hl-line (see gud-display-line), so maybe that can
be adapted to gdb disassembly buffers.
> Performing cleanup based on an event in the buffer seems fragile.
Do you mean the way I remapped top-level? This is just what is bound to
`q' in edebug-mode-map. When I'm debugging elisp code, I often quit
when I've found the bug, so this is a natural point to remove
highlighting. The code I posted doesn't remove highlighting when the
instrumented function returns, but the following does (this is rather
heavy-handed, but I can't think of a better way at the moment):
(defun my-edebug-finish ()
"Finish edebugging and remove highlighting."
(interactive)
(unless edebug-active
(hl-line-mode -1)))
(add-hook 'post-command-hook 'my-edebug-finish)
> Would it not be better to hook buffer destruction?
Well, if you kill the buffer you're debugging, that will automatically
end hl-line-mode, which is buffer-local, so in that case there's nothing
more to clean up. My approach provides highlighting only while
debugging, so when you're finished (or quit in the middle), you still
have the code buffer but no more highlighting.
> Finally, does this technique keep the line high lighted even when the
> buffer is not selected? In a normal debugging session it is the
> buffer with the gdb prompt that is selected most of the time.
The highlighting remains until removed by (hl-line-mode -1), even when
the buffer is not current.
Steve Berman
next prev parent reply other threads:[~2013-02-05 22:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 22:21 highlight current source line during debugging John Yates
2013-02-05 10:11 ` Stephen Berman
2013-02-05 14:56 ` John Yates
2013-02-05 22:36 ` Stephen Berman [this message]
[not found] ` <mailman.19067.1360076660.855.help-gnu-emacs@gnu.org>
2013-02-05 15:16 ` Sebastien Vauban
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=87ip66bd7v.fsf@rosalinde.fritz.box \
--to=stephen.berman@gmx.net \
--cc=help-gnu-emacs@gnu.org \
--cc=john@yates-sheets.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).