Re: gdb-ui, dedicated windows

[Miles Bader <miles.bader@necel.com>]

Nick Roberts <nickrob@snap.net.nz> writes:
> I still can't reproduce this, or Miles' problem whrere gdb-ui will hide the gdb
> buffer as a side-effect of popping up the source buffer (which may be a
> consequence of the GUD buffer _not_ being in a dedicated window.
...
> OK, I've just tried using gdb-ui without making windows dedicated and not
> noticed any degradation in performance.  Maybe dedicating the windows is
> historical and isn't needed now windows are split more readily.  It's really
> just evolved from my arbitrary personal use.  If you want to submit a patch and
> others, e.g., Miles, think it's an improvement, I'll be happy to install
> it.

I'm not sure what's going on really -- the window doesn't seem to be
dedicated.  I'm not sure if I am using the same setup as other people, I
just say "M-x gdb" to invoke gdb, and get, initially, just a single
*gud...* buffer.

Anyway the problem is when the frame contains only a single window, with
the *gud...* buffer; if I do M-: (window-dedicated-p (selected-window)),
the result is nil.  So, at that point, if I type in, e.g., "up RET" to
the gdb prompt, naturally it tries to display the source code of the
new frame -- but the source-code buffer _replaces_ the *gud...* buffer
in the single window, instead of splitting the frame!

It _doesn't_ seem to happen if use "emacs -Q", so I guess it's some
setting, but I'm not sure what (I don't set any gud- or gdb- variables,
and the same/special-foo variables all seem normal).

The "immediate" cause seems to be that in the variable
`gdb-source-window' is different; in my normal (non-"-Q") emacs,
gdb-source-window seems to often point to the actual window being used
to display the *gud...* buffer; I guess this causes the problem.

-Miles

-- 
Electricity, n. The cause of all natural phenomena not known to be caused by
something else.