This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFC: Project Preferences


Fernando> My proposal now is that we use "sessions" of that same file
Fernando> to store project and target specific preferences.  We can
Fernando> add the appropriate buttons to save things in the
Fernando> appropriate sessions and some simple management so we can
Fernando> save/delete/switch preferences.

The idea of using sessions sounds good.

How much of this should be exposed to the user, I don't know.  The
problem with these sorts of things is that you can make the underlying
machinery very general, but then find you have no way to build a nice
(comprehensible) UI for the user.


Lately I've gone back to always running gdb in Emacs.  Even though
this interface is quite primitive in some ways, there are some
features of Emacs that combine to make it much more useful (to me)
than gdbtk.

First, when I type `M-x gdb', Emacs prompts me to get the gdb command
line.  This prompt has command history, so I can easily select
something that I could never remember, like this (actual example):

    /x2/egcs-stuff/gdb/install/bin/gdb /x1/egcs/install/lib/gcc-lib/i686-pc-linux-gnu/2.97/jc1

I can put a line into my .emacs so that these commands are remembered
for all time (I do this with gdb commands and compilation commands
since I re-run the same ones over and over).


Next Emacs puts me into the appropriate debugger interaction buffer.
For instance for the above it would be the buffer named *gud-jc1*.
The nice thing here is that if I don't kill the buffer, then the next
time I try to debug jc1, Emacs will reuse the buffer.  This means I
can easily search backwards in the buffer and find my hairy "set args"
command, breakpoint and watchpoint commands, "dir" commands, and the
like.


I would like gdbtk (err, Insight) to be as easy to use as I find Emacs
to be.  Here is how I'd like it to work.

First, I think Insight should keep track of the programs I've most
recently debugged.  Keeping 5 or so around would be sufficient.

Next, if I select a program I've already debugged before, Insight
should automatically remember my most recent state.  It should keep
track of "dir" commands I've used and breakpoints and watchpoints
(along with attached commands and conditions) I've set.  It should
remember my working directory and the inferior's command-line
arguments.  (Maybe there are other things to remember but offhand I
don't know what.)

I realize that breakpoints and watchpoints can change.  I think this
doesn't matter.  It is easy to disable them if they are invalid -- but
it is hard to recreate them.  (This process is particularly painful
given that when debugging Java code gdb crashes all the time.)  One
idea would be to recreate all the bps and wps but disable them by
default.  I'm ambivalent about that.


Anyway, I think saving setups by "session" is fine, if the session is
the executable I'm debugging.  I think this would be the most
convenient first cut at this functionality, given my experience with
gdb-in-Emacs.

There might be even better things to do, but I don't know what they
are.  I'd rather try this out and see what flaws it reveals before
trying to design the next stage.

Any comments on this?

It turns out I've been assigned to Insight work for a while, and this
is one of the things I could actually work on.  Maybe there are other
things that have higher priority?  I'm not certain.

Tom

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]