Re: GDB-UI and multiple frames

[Nick Roberts]

 > I guess we need to first figure out:
 > - why is it bad for other buffers to occupy a "gud window".

The two windows I protect are the command and the source windows. All
other windows are equal.

 > - why do you need to track which window the source is in.

I do this to protect it from being deleted (using set-window-dedicated-p)

 > OK, here is something more concrete, although still not a solution:
 > keep track of `gdb-source-buffer' instead of (or additionally to)
 > `gdb-source-window'.  Since normally you have that
 > (eq gdb-source-window (get-buffer-window gdb-source-buffer t)), you can
 > now better react to changes in window-configs.

I made the window the invariant because the buffer name can change. This
happens when the source file gdb stops at changes or when the view changes to
assembler. "gdb --fullname" blindly pops up the appropriate source because it
is not worried about other windows and the command window is normally current
and therefore preserved.

 > Also when trying to "show source buffer A", check whether A is already
 > visible in some window and if so select that window instead of switching
 > gdb-source-window's content.

I could add this check. Is it usual to display more than one source file
while debugging?

You said earlier:

> I mostly have one frame per buffer

I had envisaged all debugger windows (apart from watch expressions in the
speedbar) being in the same frame. I felt that frames can get in each others
way while windows tile better.

 > > Can some windows be made more important than others/hard to delete/easy to
 > > redisplay contents when deleted etc?
 > 
 > Why?  Which concrete problems are you thinking of?

I was just thinking that there may be better ways to protect the command and
the source windows.

Nick