[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 17:45:36 +0200
> Date: Wed, 18 Feb 2015 16:08:21 +0100
> From: Paul K <address@hidden>
> 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?
Emacs does not generally reserve windows for buffers. If you invoke
"M-x gdb" instead, and then "M-x gdb-many-windows" (or select
GDB-MU->Display Other Windows from the menu bar), Emacs will try to
keep each window dedicated to its buffer, because this is what that
GDB interface was programmed to do.
If you cannot use "M-x gdb", then please report this as a bug using
"M-x report-emacs-bug", and perhaps someone will help you to find some
fix or customization for this situation.
> Even worse case happens when I prevent emacs from vertical split with
> following setting:
> (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.
Yes, see above.