From: David Kastrup <dak@gnu.org>
Cc: miles@gnu.org, Nick Roberts <nickrob@snap.net.nz>,
snogglethorpe@gmail.com, emacs-devel@gnu.org
Subject: Re: Multiple debugging sessions
Date: Fri, 11 Nov 2005 10:46:42 +0100 [thread overview]
Message-ID: <85fyq3ms8t.fsf@lola.goethe.zz> (raw)
In-Reply-To: <m3fyq3pow2.fsf@kfs-l.imdomain.dk> (Kim F. Storm's message of "Fri, 11 Nov 2005 09:30:53 +0100")
storm@cua.dk (Kim F. Storm) writes:
> Nick Roberts <nickrob@snap.net.nz> writes:
>
>> I was aware of the issue. The file gdba.el, which I used as my
>> starting point, used many buffer local variables, presumably to
>> allow multiple sessions. It didn't work, so I made them global.
>
> Indeed, buffer-local-variables (in source buffers) typically don't
> help if the same file/buffer is shared between multiple debugging
> sessions.
The way to do that would be to have the source buffers contain a
buffer-local variable pointing to the current debugger buffer, and
maintain all important state in buffer-local variables there.
This does not cater for multiple gdb sessions, but you can do this
somehat like that even in the most complicated cases:
(defmacro with-current-gdb-buffer (&rest form)
`(progn (while (and gdb-session-buffers
(null (buffer-name (car gdb-session-buffers))))
(pop gdb-session-buffers))
(unless gdb-session-buffers
(error "No GDB session active"))
(with-current-buffer (car gdb-session-buffers) ,@form)))
You would then get and set variables wrapped with
with-current-gdb-buffer in order to fetch the buffer-local settings
from the session.
The above loop and check may be unnecessary if gdb-session-buffers is
normally maintained by the proper buffer deletion hooks in the gdb
buffers. There would be commands to change the "current gdb session"
in a source file if there were more than one around. I don't think
that they would often be needed. An active gdb session would push its
position in the gdb-session-buffers variable of an accessed buffer to
the front.
This would almost always do the right thing and have manual override
where really necessary.
Having a list instead of a single variable actually is only necessary
so that after stepping through one file with one debugger, the
association with the previous debugger is restored. It would be
tolerable, I think, if instead the association was completely broken
and would have to be reestablished manually (by pressing RET in the
appropriate GDB session buffer or executing a special "select gdb
session" command): that way, the user might not get surprised by
unexpected debug session leftovers suddenly being in control.
In that case, the above macro just becomes
(defmacro with-current-gdb-buffer (&rest forms)
`(progn
(unless (and gdb-session-buffer (buffer-name gdb-session-buffer))
(error "No current gdb session"))
(with-current-buffer gdb-session-buffer ,@forms)))
In fact, this second approach seems programmatically simpler. A debug
session leaving a buffer would set its gdb-session-buffer variable to
nil.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
prev parent reply other threads:[~2005-11-11 9:46 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-19 2:37 `overlay-arrow-position' should be automatically buffer-local Daniel Brockman
2005-10-19 2:48 ` Ryan Yeske
2005-10-19 4:22 ` Daniel Brockman
2005-10-19 20:16 ` Richard M. Stallman
2005-10-19 6:13 ` Nick Roberts
2005-10-19 6:34 ` Ryan Yeske
2005-10-19 7:33 ` Nick Roberts
2005-10-19 20:15 ` Richard M. Stallman
2005-10-19 8:44 ` Kim F. Storm
2005-10-19 20:44 ` Ryan Yeske
2005-10-19 21:02 ` Nick Roberts
2005-10-19 21:29 ` Kim F. Storm
2005-10-20 1:43 ` Miles Bader
2005-10-20 4:45 ` Nick Roberts
2005-11-10 4:48 ` Miles Bader
2005-11-10 6:51 ` Multiple debugging sessions [was Re: `overlay-arrow-position' should be automatically buffer-local] Nick Roberts
2005-11-10 8:39 ` Multiple debugging sessions Kim F. Storm
2005-11-10 11:06 ` Miles Bader
2005-11-10 12:34 ` Kim F. Storm
2005-11-10 12:43 ` Miles Bader
2005-11-10 11:19 ` Multiple debugging sessions [was Re: `overlay-arrow-position' should be automatically buffer-local] Miles Bader
2005-11-10 18:08 ` Multiple debugging sessions Stefan Monnier
2005-11-11 1:00 ` Nick Roberts
2005-11-11 4:34 ` Stefan Monnier
2005-11-10 19:12 ` Nick Roberts
2005-11-10 22:10 ` Andreas Schwab
2005-11-12 3:38 ` Richard M. Stallman
2005-11-12 4:56 ` Nick Roberts
2005-11-12 5:53 ` Miles Bader
2005-11-12 6:50 ` Eli Zaretskii
2005-11-12 21:23 ` Richard M. Stallman
2005-11-12 22:15 ` Nick Roberts
2005-11-11 0:31 ` Miles Bader
2005-11-11 1:03 ` Miles Bader
2005-11-11 9:12 ` Kim F. Storm
2005-11-11 19:34 ` Juri Linkov
2005-11-11 3:50 ` Nick Roberts
2005-11-11 4:36 ` Stefan Monnier
2005-11-11 7:41 ` Richard M. Stallman
2005-11-11 9:22 ` Eli Zaretskii
2005-11-12 3:38 ` Richard M. Stallman
2005-11-11 8:30 ` Kim F. Storm
2005-11-11 9:46 ` David Kastrup [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85fyq3ms8t.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
--cc=nickrob@snap.net.nz \
--cc=snogglethorpe@gmail.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.