Re: Using gdb (windows popping up)

[jonetsu <jonetsu@teksavvy.com>]

On Mon, 10 Jun 2019 00:36:08 +0200
Óscar Fuentes <ofv@wanadoo.es> wrote:

> There is a huge difference. A new Emacs instance does not share state
> with other instances.
> 
> A frame is just what in modern GUI terminology is known as a toplevel
> window, or what most users call a window. An Emacs instance can have
> multiple frames, just like the same Firefox or LibreOffice instance
> can have multiple windows.

Yes, but for all user/practical purposes it is another instance in the
sense that another 'app' is popping up showing the source code, hiding
the other emacs beneath it, while the gdb interactive buffer remains in
this 'other app' underneath.

The effect wished by the user is one of having the gdb interactive
buffer side-by-side with the source code as the debugging execution is
made. Which is fairly normal, if not totally useful.  New frame or
new instance, the user effect remains the same: the source code is no
longer beside the debugging session.

As a summary, setting gdb-display-io-nopopup to non-nil adds a lot of
stability to what was otherwise termed as an "aggressive" approach of
popping up a frame.  

It adds a lot of stability, which is a way of saying that there's still
a bit of jitter at the beginning of a M-x gdb session, when the gdb
input/output window is brought up.  At that moment there's still a bit
of a brawl as emacs insists to order windows contrary to what the user
normally expects from emacs, but that can be dealt with and from there
on a stability is assured for the debugging session and the user has a
good amount of freedom in placing windows and buffers as they are
deemed to be: the usual emacs way.

gdb-display-io-nopopup (since emacs 25) seems to be the best solution
to a problem that perhaps should not have been there from the start.