bug#17675: 24.4.50; *gud* buffer keeps on getting buried

[Michael Welsh Duggan]

martin rudalics <rudalics@gmx.at> writes:

>> At this point, notice that *gud-foo* buffer is gone, as foo.c has
>> replaced it.  At some point in time in the past, foo.c would end up
>> replacing the other window (the *scratch* buffer).  That would be the
>> desired behavior, as I would be able to continue using the *gud* buffer.
>>
>>      C-x 4 b RET   (accepting default "*gud-foo*")
>>      n RET RET
>>
>> Now *input/output of foo* replaced the *gud-foo* buffer.  I can't say
>> much about this, as I normally use gdb a different way.  But it seems
>> sub-optimal.  For my usual debugging habits, see Sequence 2.
>
> Here ...
>
>> Same set-up as for sequence 1, then as follows:
>>
>>      M-x gud-gdb RET
>>      RET               (accepting default "gdb --fullname foo")
>>      start RET
>>
>> At this point, notice that *gud-foo* buffer is gone, as foo.c has
>> replaced it.  At some point in time in the past, foo.c would end up
>> replacing the other window (the *scratch* buffer).  That would be the
>> desired behavior, as I would be able to continue using the *gud* buffer.
>
> ... and here it would be helpful to check whether `display-buffer' runs
> `display-buffer-use-some-window' and why it uses that window.  I usually
> edebug this from a second frame.

It's being selected by display-buffer-in-previous-window in this
particular test case.  Maybe gud needs to bind inhibit-same-window to t
before calling display-buffer (from gud-display-line).

-- 
Michael Welsh Duggan
(md5i@md5i.com)