From: Nick Roberts <nickrob@snap.net.nz>
To: Richard G Riley <rileyrgdev@gmail.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: GUD/GDB in emacs
Date: Sat, 19 Jul 2008 14:03:36 +1200 [thread overview]
Message-ID: <18561.19320.854676.502740@kahikatea.snap.net.nz> (raw)
In-Reply-To: <g5pkbn$kl6$1@registered.motzarella.org>
Richard G Riley writes:
> Nick Roberts <nickrob@snap.net.nz> writes:
>
> > > > I'm not sure what you mean exactly. Maybe expand a node in situ in the
> > > > locals buffer, for example.
> > >
> > > That would seem the obvious solution and is the case in other IDEs. e.g
> > > you see "p" in the locals (where p is a pointer to a struct for example)
> > > and then can see the struct by double clicking it for example. Pretty
> > > much what the speedbar does but without the speed bar.
> >
> >
> > I think Insight does this but ISTR Totalview uses a separate frame.
> > Expanding
>
> I'm not familiar with these things. They are Emacs packages?
No, they're debuggers.
> > in situ makes it harder to find the other locals. In fact I'm
> > thinking of
>
> Expand, shrink. They only impede if you expand them. If you expand them
> they are expanded for a reason generally. But as you point out below the
> vocab we are using (because of what is there) can confuse us. "Watch" in
> this case is the only apparent way to expand a pointer to a struct. We
> should really just be discussing how to view a dereferenced pointer -
> DDD does this quite nicely. But being an Emacs convert it would be nice
> to have the same, or similar, in the GUD interface.
I've not used DDD much but I found the data window (= watch expressions?)
awkward. You can view structures in the GUD buffer with "set print pretty"
and the "print" command (also on the tool bar and C-x C-a C-p).
> > using a separate frame for each watch expression, something which isn't
> > really possible with the speedbar. This would be helpful for arrays and
> > large structures.
>
> A separate frame for each expression would be a collossal waste of
> screen real estate and possibly worse than the current speed bar
> implementation IMO.
As you say, they only impede if you expand them. Data structures can be large
and need their own frame/window. It would also be a way to limit the number
of children that need to be created.
--
Nick http://www.inet.net.nz/~nickrob
prev parent reply other threads:[~2008-07-19 2:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 22:42 GUD/GDB in emacs Richard G Riley
2008-07-16 23:57 ` Nick Roberts
[not found] ` <mailman.14873.1216252651.18990.help-gnu-emacs@gnu.org>
2008-07-17 0:11 ` Richard G Riley
2008-07-17 20:46 ` Nick Roberts
[not found] ` <mailman.14905.1216329307.18990.help-gnu-emacs@gnu.org>
2008-07-18 8:30 ` Richard G Riley
2008-07-19 2:03 ` Nick Roberts [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
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=18561.19320.854676.502740@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=help-gnu-emacs@gnu.org \
--cc=rileyrgdev@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.
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).