[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using gdb (windows popping up)
From: |
jonetsu |
Subject: |
Re: Using gdb (windows popping up) |
Date: |
Sun, 9 Jun 2019 12:09:08 -0400 |
On Sun, 9 Jun 2019 11:52:46 -0400
jonetsu <jonetsu@teksavvy.com> wrote:
> ... until the debugging session starts. At which point emacs decides
> to create a new whole emacs app/window with the source code in it. It
> boldly replaces the source window with the debugged app's output
> window and throws the source into a new emacs instance.
Using sr-speedbar-open prior to starting gdb solves the problem of
popping up a new emacs instance. That is, sr-speedbar with the
following added in .emacs (which I found in stack exchange, regarding
speedbar not being able to use the current emacs frame)
(defadvice delete-other-windows (after
my-sr-speedbar-delete-other-window-advice activate) "Check whether we
are in speedbar, if it is, jump to next window." (let ()
(when (and (sr-speedbar-window-exist-p sr-speedbar-window)
(eq sr-speedbar-window (selected-window)))
(other-window 1)
)))
(ad-enable-advice 'delete-other-windows 'after
'my-sr-speedbar-delete-other-window-advice) (ad-activate
'delete-other-windows)
Since emacs/gdb will use speedbar anyways to display watch items, might
as well load it up front.
So this seems to resolve the problem with new instances popping up.
- Using gdb (windows popping up), jonetsu, 2019/06/09
- Re: Using gdb (windows popping up),
jonetsu <=
- Re: Using gdb (windows popping up), Eli Zaretskii, 2019/06/09
- Re: Using gdb (windows popping up), jonetsu, 2019/06/09
- Re: Using gdb (windows popping up), Eli Zaretskii, 2019/06/09
- Re: Using gdb (windows popping up), jonetsu, 2019/06/09
- Re: Using gdb (windows popping up), Noam Postavsky, 2019/06/09
- Re: Using gdb (windows popping up), jonetsu, 2019/06/09
- Re: Using gdb (windows popping up), Noam Postavsky, 2019/06/09