unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nick Roberts <nick@nick.uklinux.net>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs mode for GDB
Date: Tue, 21 May 2002 13:32:31 +0100	[thread overview]
Message-ID: <15594.15967.58479.315156@nick.uklinux.net> (raw)
In-Reply-To: <buobsbavwxc.fsf@mcspd15.ucom.lsi.nec.co.jp>

Miles Bader writes:
 > 
 > (1) I get the following error regularly:
 > 
 >  error in process filter: gdb-output-burst: Symbol's function definition  
 >  is void: gdb-display-end
 >  error in process filter: Symbol's function definition is void: 
 >  gdb-display-end
 > 
 >  Indeed there seems to be no such function `gdb-display-end'.
 
Thats right there is currently no gdb-display-end (or gdb-display-begin). 
Examining data (array slices, diving into structures) is on of the things
that I want to do next.  Currently if you comment out the two items :

   ("display-begin" gdb-display-begin)
   ("display-end" gdb-display-end)
 
in the variable gdb-annotation-rules the error above should go away and any
variables or expressions that you display should just appear in the GUD buffer
(or possibly the Input/Output buffer!).

 > (2) Completion doesn't work on the gdb command line like it does in
 >     the standard gdb-mode.

Hmm. No, gdba.el doesn't seem to have it either. I must have lost it in the 
merge. I'll try to put it back.

 > (3) The file `gdb.el' is apparently constructed in large parts from the
 >     existing `gud.el', with much of the functionality of gud removed (in
 >     particular, support for non-gdb debuggers).  Is that necessary?

Its just a starting point to help me get something working. At the beginning
I wasn't very familiar with gud.el as lisp code and I hadn't even heard of 
gdba.el

 >     If emacs were to use your gdb.el unchanged, it would result in a
 >     huge amount of duplicated code between gdb.el and gud.el; it would
 >     be nicer to either continue to use gud.el, with new features added,
 >     or otherwise avoid code duplication.
 
I guess it could either be folded back into gud.el or gdb.el could have the line
`(require 'gud)' in it and the autoloading of the main lisp function gdb could
be suppressed in gud.el. There may be some conflicts in namespace which could
possibly be resolved by changing the prefix gud- to gdb- for some functions
and variables.

 > (4) With all the windows displayed, it requires a lot of space.  It
 >     would be nice to have some way of specifying which windows get
 >     used -- for instance, the breakpoint window can be displayed only
 >     if there are breakpoints, and when tested it, I didn't need the
 >     backtrace, or I/O windows either, so I'd like to be able to disable
 >     them.

 There is a variable called gdb-many-windows which if set to nil will suppress
 the display of the ancillary buffers.  However, you need the breakpoints
 buffer for proper display of the breakpoint icons as they are updated by the
 relevant annotation from gdb. Incidentally, the toolbar could be inserted
 directly in gud.el (I think) without much alteration.

 > (5) You should keep the historical author information in the file header
 >     comment.

The code is in a state of turmoil at the moment. Some author information for
gud.el is included a short way down. However, it doesn't say in gdba.el who
the authors were. When the code is complete, I will try to deal with this matter
properly.

  reply	other threads:[~2002-05-21 12:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-20 22:45 Emacs mode for GDB Nick Roberts
2002-05-20 22:04 ` Eli Zaretskii
2002-05-20 22:15 ` Colin Walters
2002-05-21  6:26 ` Miles Bader
2002-05-21 12:32   ` Nick Roberts [this message]
2002-05-21 20:42   ` Richard Stallman
2002-05-21 13:24 ` Andreas Fuchs
2002-05-21 20:37   ` Nick Roberts
  -- strict thread matches above, loose matches on Subject: below --
2002-06-13 17:54 Nick Roberts
2002-05-20 22:36 Nick Roberts

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=15594.15967.58479.315156@nick.uklinux.net \
    --to=nick@nick.uklinux.net \
    --cc=emacs-devel@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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).