[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GDB-UI and multiple frames
From: |
Nick Roberts |
Subject: |
GDB-UI and multiple frames |
Date: |
Sat, 3 Apr 2004 19:45:09 +0100 |
> The buffer/window management of GDB-UI clashes very badly with my setup.
> It insist in ignoring all but the frame where I have the *gud* buffer:
>
> - So it splits it into two or three parts and shows me some source buffer
> in there. OK, many other Emacs packages assume one-frame and split
> things when I don't want them to,but I can live with it.
> - So I just delete the annoying window with C-x 0 (maybe after C-x 5 2
> to show the relevant buffer in a separate frame instead).
> - I run my program and next thing I know it crashes in gdb-frame-handler
> when doing set-window-buffer because gdb-source-window is not a live
> window any more. OK, now that's plainly a bug.
The source window shouldn't display until you hit a breakpoint now. You don't
say which window you deleted, but I'll admit that deleting the source window
will, in general, confuse GDB-UI. Maybe its poor design but its only really a
bug if you can propose something better. Other modes which use multiple
buffers (ediff, emerge, smerge etc) always have a fixed number of
windows. GDB-UI can use a variable number. gdb-restore-windows is a good way
to recover but it will only return to a standard layout.
> - To work around the bug, I do (setq gdb-source-window nil) and next thing
> you know GUD shows me the assembly code in the window where I had *gud*
> (that's a poor choice, but it's a strange situation anyway, I won't hold
> it against gdb-ui for it).
gdb-source-window is meant to be an internal variable. Thats a bit like
changing the timing on a car and then complaining that it won't start.
> - Now, I want to fix the above so I...
Fit new spark plugs?
> I think the notion of gdb-source-window just plain does not fit my usage
> pattern (I mostly have one frame per buffer). Short of using the old
> "gdb --fullname" interface, what can I do?
I guess first of all there should be a consensus as to how the mode _should_
work. However, I'm not sure that enough people have really used it to reach a
collective agreement. The problem that I have had in designing it so far, is
marking the GUD and source buffer as special, so that new buffers do not
indvertantly occupy their window and so that GDB-UI can track which window the
source is in (which presumably should be visible at all times once execution
has started).
Can some windows be made more important than others/hard to delete/easy to
redisplay contents when deleted etc?
Nick
Re: GDB-UI and multiple frames, Richard Stallman, 2004/04/04