unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: emacs 24.4.1, gud-gdb, problem: at breakpoint hit, *gud* buffer	is replaced with source code buffer
Date: Wed, 18 Feb 2015 17:45:36 +0200	[thread overview]
Message-ID: <838ufv5ilb.fsf@gnu.org> (raw)
In-Reply-To: <CAA+mFXPu1Fd3+NngjV+rp9R1e_P9PQ0S1LuSpw2bQ=eyoz6H7Q@mail.gmail.com>

> Date: Wed, 18 Feb 2015 16:08:21 +0100
> From: Paul K <mafeuser@gmail.com>
> 
> 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
> breakpoint.
> 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.



      reply	other threads:[~2015-02-18 15:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 15:22 emacs 24.4.1, gud-gdb, problem: at breakpoint hit, *gud* buffer is replaced with source code buffer Paul K
2015-02-18 15:08 ` Paul K
2015-02-18 15:45   ` Eli Zaretskii [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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=838ufv5ilb.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).