From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Using gdb (windows popping up)
Date: Sun, 09 Jun 2019 22:13:08 +0300 [thread overview]
Message-ID: <83ef42bmij.fsf@gnu.org> (raw)
In-Reply-To: <20190609145921.0fc60f3c@mistral> (message from jonetsu on Sun, 9 Jun 2019 14:59:21 -0400)
> 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.
next prev parent reply other threads:[~2019-06-09 19:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-09 15:52 Using gdb (windows popping up) jonetsu
2019-06-09 16:09 ` jonetsu
2019-06-09 16:18 ` jonetsu
2019-06-09 16:58 ` jonetsu
2019-06-09 17:48 ` Óscar Fuentes
2019-06-09 18:31 ` Eli Zaretskii
2019-06-09 18:59 ` jonetsu
2019-06-09 19:13 ` Eli Zaretskii [this message]
2019-06-09 19:27 ` jonetsu
2019-06-09 19:33 ` Noam Postavsky
2019-06-09 19:48 ` jonetsu
2019-06-09 20:15 ` Noam Postavsky
2019-06-09 21:10 ` jonetsu
2019-06-09 22:36 ` Óscar Fuentes
2019-06-10 13:33 ` jonetsu
2019-06-10 13:44 ` Óscar Fuentes
2019-06-10 14:00 ` jonetsu
2019-06-10 15:44 ` Eli Zaretskii
2019-06-10 18:52 ` jonetsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ef42bmij.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.