Re: GDB startup

[Nick Roberts <nickrob@snap.net.nz>]

 > Maybe another approach is to limit the buffers that are considered to some
 > set of major modes, or to some subtree of the filesystem.  But neither seems
 > quite practical.
 >
 > Another alternative could be to handle the files/buffers "slowly", with
 > a 0.5s delay between each file/buffer, starting with the buffers that are
 > currently visible.

I'm not sure that I like either of these very much but here are other
alternatives. Currently gdb-ui.el uses the GDB command "info source" to find
out if a file is part of the source code of the debug session.  There is
another command, "info sources", that lists all the files that are part of the
source code. Unfortunately only recent versions of GDB give the full pathname
for these files, and as it is CLI output the exact syntax might not always be
consistent. However, there is also an MI command,
-file-list-exec-source-files, that provides this information in a way that can
be parsed more simply. This command was added in GDB 6.2, I think.

I have also modified MI commands so that, in Emacs, the locals buffer and
watch expressions in the speedbar display better information more quickly.
These changes were added in version 6.1. GDB get released about two times a
year and the current version is 6.3.

There is a choice to be made before the next release of Emacs:

1) We can use these new features to improve the behaviour/performance of Emacs
   with GDB and accept that it won't work with older versions of GDB.

or

2) We can accept the current behaviour/performance so that it works with older
   versions of GDB.

As time goes by, 1) becomes more attractive but because there has been no
timeline for its release since the "feature freeze" ten months ago (it might
be next week or it might be next year) I have conservatively followed 2).


Nick