From: jonetsu <jonetsu@teksavvy.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Using gdb (windows popping up)
Date: Mon, 10 Jun 2019 14:52:12 -0400 [thread overview]
Message-ID: <20190610145212.56e60e7e@mistral> (raw)
In-Reply-To: <835zpdbg28.fsf@gnu.org>
On Mon, 10 Jun 2019 18:44:47 +0300
Eli Zaretskii <eliz@gnu.org> wrote:
> One again, the GDB UI was _designed_ to work in dedicated windows,
> something that few Emacs features do. I suggest not to fight that,
> but instead find a way of coexisting peacefully with that design.
And indeed, the approach I described in the last replies results in a
comfortable setup, which just a little bit of jitter at the beginning.
> One way of coexisting peacefully is to invoke "M-x gdb" in a new
> frame. That is, first type "C-x 5 2" to create a new frame, then
> invoke "M-x gdb" in that new frame. This way, your window arrangement
> in the original frame will be left intact. Switching to that original
> frame is easy both with a mouse and via keyboard, so this is what the
> Emacs manual recommends.
Yes, I'll keep that in mind if needed, although the current approach
with gdb-display-io-nopopup set to non-nil is not bad at all as far as
getting close to a normal emacs use.
> You can save the customization of gdb-many-windows with a non-nil
> value for your future sessions, in which case Emacs will start with
> all the UI windows right after you invoke "M-x gdb", thus avoiding
> this temporary "disruption" altogether.
This is what I tried right before starting this thread (described in
the previous thread by me) and abandoned the approach altogether since
it becomes way too difficult to show dedicated non-gdb buffers which I
need during debugging as I take notes, refer to notes, refer to other
sources, etc. I could switch to another frame (equivalent of another
app for all practical user interface purposes since it requires
switching over - switching over to another full screen frame on the
same desktop or another desktop) although I still like to do everything
in one emacs session/frame/instance, as I'm used to work with emacs.
The bottom line to this is that some people have decided that gdb (many
windows option) should be presented in a very specific way when there's
no need to do so at all, none whatsoever. The user is absolutely
capable of freely choosing which gdb buffers to be shown and where,
while have full co-existence with any other buffers. There are no
logical reasons to impose a specific placement of gdb buffers. It will
not make debugging work better. The chosen imposed presentation (many
windows option) is not adding any performance improvement to
debugging. gdb has a lot of functions and IMHO any development in gud
would be towards integrating more of those functions - while not
imposing anything on the users.
prev parent reply other threads:[~2019-06-10 18:52 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
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 [this message]
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=20190610145212.56e60e7e@mistral \
--to=jonetsu@teksavvy.com \
--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.