RFC: Project Preferences

RFC: Project Preferences

[Fernando Nasser]

One week or two ago I have asked for suggestion on where to put a 
projects preference file.

No one came with a solution.  The reason is that there is none for the
model I was thinking off.  Silly me, that was the wrong model.

It seems clear to me now that the only "standard" location is the user's
home directory.  And we already have a file in there  --  the "global"
preferences file.

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

I came with this "target" preferences class when I was trying to determine
what should be global or project specific. For instance, the set of registers
that are shown or not are target, not project, specific.  We may allow someone
to override them for a specific project as well, but they tend to be the same
for all targets of the same kind.


Anyway, if nobody objects to the "sessions" approach, we can proceed to design.


We, of course, will need a volunteer to implement it.  I myself can do it in
December if none is available until then.

A nice person to implement this would be Larry Smith (he fixed some preferences
stuff the other day), but he is currently taking care of screening problem
reports and enhancement requests that have been accumulating.


Well, if someone else is up to it let me know.  But I really need to get this
in place before 2001.  I can't enter the new millennium (the real one) 
having to go through the Target Selection dialog every time. ;-)


P.S.: Don't forget that you need an assignment to contribute significant
      changes or new features.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: RFC: Project Preferences

[Tom Tromey]

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