[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs 24.4.1, gud-gdb, problem: at breakpoint hit, *gud* buffer is r
Re: emacs 24.4.1, gud-gdb, problem: at breakpoint hit, *gud* buffer is replaced with source code buffer
Wed, 18 Feb 2015 16:08:21 +0100
I'm trying to isolate the problem:
1) prompt$ emacs -q #. way I run emacs
2) I visit directory that contains binary I want to debug. It is on remote
linux box (so emacs uses tramp to open it).
2) M-x gud-gdb.
3) I set two breakpoints. Each of them is in different C++ source file.
4) I split my emacs frame into two windows. Upper window contains
*gud-proc* buffer. Lower window contains source file that contains second
5) I start program
6) First breakpoint is hit.
Crazy thing: emacs splits upper window into two windows, this time
veritcally. Upper left window contains *gud-proc*, while upper right
contains source file with first breakpoint.
I'd expect lower window should display the source file that contains
first breakpoint instead. No new window should be created by emacs.
Am I wrong?
How to force emacs not to display another window?
Even worse case happens when I prevent emacs from vertical split with
(setq split-width-threshold nil)
Then, at step 6 above, no new window is created, but instead, *gud-proc*
buffer, that is dislayed in upper window is replaced with source file that
keeps the first breakpoint.
Maybe these two problems have the same root cause.
On Tue, Feb 17, 2015 at 4:22 PM, Paul K <address@hidden> wrote:
> Hallo people.
> I'm debugging C++ files with M-x gud-gdb.
> I set the breakpoint is some source file.
> *gud-gdb* occupies one half (top or bottom) of frame, while source buffer
> occupies other one.
> Then I visit another source file and another....
> Now I start the program or just rerun it from *gud-procname* window and
> when breakpoint is hit, SOMETIMES emacs visits the source file in
> *gud-procname* window, while it should visit it in another one, so that to
> prevent *gud-procname* from disappearing.
> Have You got any idea what might be the reason?
> If not, could You please tell me where to hook with edebug-defun?
> best regards,