Re: Using gdb (windows popping up)

[Eli Zaretskii]

> Date: Sun, 9 Jun 2019 14:59:21 -0400
> From: jonetsu <jonetsu@teksavvy.com>
> 
> > As yet another alternative, customize gdb-show-main to a non-nil
> > value, and then "M-x gdb" will automatically show the source file with
> > the main function in a window; switch in that window to your other
> > source file where you want to set a breakpoint, then start the
> > program.
> 
> Yes, gdb-show-main is set to non-nil.  And yes, it will then show the
> source beside the gdb interactive buffer.... until a printf/cout
> statement is issued at which point the input/output window will
> "aggressively" - as it was termed in a Stack Exchange topic - take over
> and decide where any other buffer you deem to see will be actually
> located.

That's a different issue.  Your original complaint was about popping
up source buffers, and that's what I was trying to help you with.

> Fortunately, the fix I found, setting gdb-display-io-nopopup
> (starting at emacs 25) to non-nil solves the issue and brings back
> peace of mind regarding the expected freedom one expects in emacs
> regarding placing buffers where one wants them.  In other words, if
> removes a good part of the tool's quirks in this context and enables
> one to concentrate on work.

So the problem is solved.  I'm glad.

My personal advice is to start the debugging session with "M-x
gdb-many-windows", which will open all the UI windows, including I/O.
I believe in this case the program's output will be inserted into the
I/O window, and will not usurp any of your other windows.

> That such behaviour found its way in emacs is something else.  Imagine
> any power tool built wit such quirkiness. 

Once again, the GDB-MI UI was designed to work with dedicated windows,
to mimic GUI front ends to debuggers.  The user manual even advises to
start "M-x gdb" in a separate frame, so as not to interfere with any
window arrangement you may be using when not debugging.