Re: GDB-UI and multiple frames

[Stefan Monnier]

> will, in general, confuse GDB-UI.  Maybe its poor design but its only
> really a bug if you can propose something better.

Well, I sent my report before coming up with a proposal because I figured
maybe you could help out ;-)

>> - 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.

Yes, that's what I meant by "strange situation".

>> 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.

I'm not sure such a think exists.  Different users use their
tool differently.  I think a real issue is that some people like me used to
the Emacs-21.2 M-x gdb behavior will be annoyed by the much more intrusive
buffer/window management, so I think we need a way to make it
less intrusive.  This may require config-variables.

> However, I'm not sure that enough people have really used it to reach
> a collective agreement.

I expect that some people will really like it, and others will be
mighty annoyed.

> 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).

I guess we need to first figure out:
- why is it bad for other buffers to occupy a "gud window".
- why do you need to track which window the source is in.

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.

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.

> 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?


        Stefan