> 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 _______________________________________________ Emacs-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-devel
