gdb-ui, dedicated windows

[David Hansen-2]

Hello,

when `gdb-many-windows' is nil some windows (e.g. the window displaying
the stack buffer) are dedicated.

This may make sense with `gdb-many-windows' set to t but I find it
pretty annoying with a nil value.  I just looked at a long stack trace
displayed in the only window of the frame.

When I hit RET to jump to the interesting source Emacs popped up a new
frame.  IMHO it's very bad behavior to pop up a frame unless explicitly
asked to do so.

Do these windows have to be dedicated?

Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
dedicated window even if `gdb-many-windows' is t.  It just takes to much
space and makes it hard to look at two source files at the same time.

BTW, how about some key bindings to move around / display the gdb-ui
windows?

David

[Nick Roberts]

 > when `gdb-many-windows' is nil some windows (e.g. the window displaying
 > the stack buffer) are dedicated.
 >
 > This may make sense with `gdb-many-windows' set to t but I find it
 > pretty annoying with a nil value.  I just looked at a long stack trace
 > displayed in the only window of the frame.

Dedicating windows gives some control over window configuration.  Even if
gdb-many-windows is nil the user might choose to display buffers manually
that give a similar configuration to when it is t.

 > When I hit RET to jump to the interesting source Emacs popped up a new
 > frame.  IMHO it's very bad behavior to pop up a frame unless explicitly
 > asked to do so.

I use gdb-many-windows with a nil value and often just display the stack trace
in a separate frame (via the menubar) and I don't see this.  There must be
other factors like pop-up-frames being t, or the GUD and/or source buffer
killed or not being visible etc.

In order for me to accommodate your pattern of use, you need to provide a
recipe that illustrates the problem.

 > Do these windows have to be dedicated?

Not making them dedicated might fix your specific problem but would surely
cause others.  Currently window placement relies on heuristics and it will
probably always be possible to find a usage pattern where gdb-ui has annoying
behaviour.

It is this kind of problem, inspired by examining ECB, that has led to some
people to look at the concept of window groups, as discussed earlier this
year on the mailing list.

 > Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
 > dedicated window even if `gdb-many-windows' is t.  It just takes to much
 > space and makes it hard to look at two source files at the same time.

If it takes up too much room why use a separate buffer?  If you need a
separate buffer, why not put it in another frame?


 > BTW, how about some key bindings to move around / display the gdb-ui
 > windows?

It would be nice to be able to move the buffers around like views in Eclipse
but that would be a substantial task.  Emacs 23 has tabs in the header line
of some buffers.  Do you have any concrete ideas?


--
Nick                                           http://www.inet.net.nz/~nickrob

[David Hansen-2]

On Sat, 5 Jul 2008 22:02:29 +1200 Nick Roberts wrote:

>  > when `gdb-many-windows' is nil some windows (e.g. the window displaying
>  > the stack buffer) are dedicated.
>  >
>  > This may make sense with `gdb-many-windows' set to t but I find it
>  > pretty annoying with a nil value.  I just looked at a long stack trace
>  > displayed in the only window of the frame.
>
> Dedicating windows gives some control over window configuration.  Even if
> gdb-many-windows is nil the user might choose to display buffers manually
> that give a similar configuration to when it is t.

Well, if it is nil, the user obviously wants to control windows as he
wants, at least that's the reason why I toggle off many windows from
time to time.

>  > When I hit RET to jump to the interesting source Emacs popped up a new
>  > frame.  IMHO it's very bad behavior to pop up a frame unless explicitly
>  > asked to do so.
>
> I use gdb-many-windows with a nil value and often just display the stack trace
> in a separate frame (via the menubar) and I don't see this.  There must be
> other factors like pop-up-frames being t, or the GUD and/or source buffer
> killed or not being visible etc.

I use two frames, one for GNUS and one for everything else.
`pop-up-frames' is nil.

> In order for me to accommodate your pattern of use, you need to provide a
> recipe that illustrates the problem.

In this case only one window was displayed (the stack trace).  No other
emacs frame on the "virtual desktop" (or whatever this is called).

>  > Do these windows have to be dedicated?
>
> Not making them dedicated might fix your specific problem but would surely
> cause others.  Currently window placement relies on heuristics and it will
> probably always be possible to find a usage pattern where gdb-ui has annoying
> behaviour.

But why does gdb-ui wants to manage windows in the first place (if "many
windows" is nil)?  I don't quite see what it wants to achieve with it and
what can't be done with the usual functions (switch-to, display, ...).

> It is this kind of problem, inspired by examining ECB, that has led to some
> people to look at the concept of window groups, as discussed earlier this
> year on the mailing list.

See above.

>  > Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
>  > dedicated window even if `gdb-many-windows' is t.  It just takes to much
>  > space and makes it hard to look at two source files at the same time.
>
> If it takes up too much room why use a separate buffer?  If you need a
> separate buffer, why not put it in another frame?

Another frame uses the same space (even some pixels more for the
decoration!).  I'm just used to Emacs keys for switching windows.  Even
though my window manager behaves very similar it's just not the same...

But as I said, that's not a real problem for me, I stopped using a
separate IO buffer and don't miss it much.

>  > BTW, how about some key bindings to move around / display the gdb-ui
>  > windows?
>
> It would be nice to be able to move the buffers around like views in Eclipse
> but that would be a substantial task.  Emacs 23 has tabs in the header line
> of some buffers.  Do you have any concrete ideas?

At the time I use window-number.el (found on the emacswiki).  It's a
little minor mode that puts a number in the mode line and you can switch
windows via C-x C-j <n>.

It's very nice for gdb-ui with many windows but I think mnemonic
bindings would be better than numbers (I rarely use C-x C-j <n> outside
of gdb-ui).  There must be some C-c C- binding free...

David

[Miles Bader-2]

Nick Roberts <nickrob@...> writes:
>  Currently window placement relies on heuristics and it will
> probably always be possible to find a usage pattern where gdb-ui has annoying
> behaviour.

The one which hits me a lot is that often gdb-ui will _hide the gdb
buffer_ as a side-effect of popping up the source buffer... :-(

-Miles

--
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

[Tom Tromey]

>> Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
>> dedicated window even if `gdb-many-windows' is t.  It just takes to much
>> space and makes it hard to look at two source files at the same time.

Nick> If it takes up too much room why use a separate buffer?  If you need a
Nick> separate buffer, why not put it in another frame?

The effect I would like is to have a single, screen-filling "gdb UI"
frame show up when I start debugging, and have it go away when I
finish debugging.  And, I'd like to be able to arrange the windows in
this frame the way I like.

The "one frame" approach is vaguely reminiscent of an Eclipse
perspective.  FWIW I think it is reasonable for some people to want
multiple frames and some to want a single frame.

To achieve this, a few changes are needed.  First, Emacs needs a new
way to maximize a frame so it doesn't overshadow the panel.  Second,
gdb-ui needs some window layout code.

>> BTW, how about some key bindings to move around / display the gdb-ui
>> windows?

Nick> It would be nice to be able to move the buffers around like
Nick> views in Eclipse but that would be a substantial task.  Emacs 23
Nick> has tabs in the header line of some buffers.  Do you have any
Nick> concrete ideas?

A while back I wrote the appended.  It isn't perfect, but the idea is
that you can rearrange the windows by hand, then save the state.
Then, next time, M-x gdb-frame-restore-windows will use this window
layout instead of the built-in one.

A few unimplemented refinements: have gdb-ui do this automatically,
save the window configuration, and allow multiple "source" windows w/
LRU replacement.

Tom

;;; gdb-frame.el --- new frame for gdb

;; Copyright (C) 2007 Tom Tromey <tromey@...>

;; Author: Tom Tromey <tromey@...>
;; Created: 15 Sep 2007
;; Version: 0.1
;; Keywords: tools

;; This file is not (yet) part of GNU Emacs.
;; However, it is distributed under the same license.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:

;;; Code:

(defvar gdb-application-frame nil)

(defun gdb-get-application-frame ()
  (unless (frame-live-p gdb-application-frame)
    (setq gdb-application-frame
          (make-frame '((title . "Emacs - GDB")
                        (tool-bar-lines . 1)
                        (height . 55)
                        (width . 183)))))
  (raise-frame gdb-application-frame)
  (select-frame-set-input-focus gdb-application-frame)
  gdb-application-frame)

(defun tjt-gdba (command-line)
  (interactive (list (gud-query-cmdline 'gdba)))
  (when (and (eq window-system 'x) gdb-many-windows)
    (gdb-get-application-frame))
  (gdba command-line))

(defvar gdb-frame-saved-windows nil)

(defun gdb--restore-windows-mapper (window-symbol window)
  (if (eq window-symbol 'gdb-source-window)
      ;; Assumes just one source window in the tree.
      (setq gdb-source-window window)
    (set-window-buffer window (gdb-get-buffer window-symbol))))

(defun gdb--restore-windows (parent-window tree map-fn)
  (let* ((vertical (nth 0 tree))
         (edges (nth 1 tree))
         (window-spec (nthcdr 2 tree)))
    (while window-spec
      (let* ((elt (car window-spec))
             next-window)
        (if (cdr window-spec)
            (setq next-window
                  ;; 'elt' here works for both the vector children and
                  ;; the list children.
                  (split-window parent-window (elt elt 1) (not vertical))))
        (if (vectorp elt)
            (funcall map-fn (elt elt 0) parent-window)
          (gdb--restore-windows parent-window elt map-fn))
        (setq parent-window next-window)
        (setq window-spec (cdr window-spec))))))

(defun gdb-frame-restore-windows ()
  (interactive)
  ;; Don't bother if we just had a single window.
  (delete-other-windows)
  (unless (symbolp gdb-frame-saved-windows)
    (gdb--restore-windows (selected-window) gdb-frame-saved-windows
                          #'gdb--restore-windows-mapper)))

(defun gdb--save-window-mapper (alist window)
  (if (eq window gdb-source-window)
      'gdb-source-window
    (or (cdr (assq (window-buffer window) alist))
        'gdb-source-window)))

(defun gdb--rewrite-window-tree (tree horizontal map-fn)
  (if (windowp tree)
      ;; Rewrite the window according to the mapper.
      ;; Also check for the source window.
      ;; If we don't understand what we have, assume it is the source.
      (let ((size (if horizontal
                      (window-height tree)
                    (window-width tree))))
        (vector (funcall map-fn tree) size))
    (append (list (nth 0 tree)
                  (let ((sizes (nth 1 tree)))
                    (if (nth 0 tree)
                        (- (nth 2 sizes) (nth 0 sizes))
                      (- (nth 3 sizes) (nth 1 sizes)))))
            (mapcar (lambda (item)
                      (gdb--rewrite-window-tree item (nth 0 tree) map-fn))
                    (nthcdr 2 tree)))))

(defun gdb-frame-save-windows ()
  (interactive)
  (let ((buffer-map
         ;; Map buffers to symbolic buffer names.
         (delq nil
               (mapcar (lambda (elt)
                         (let ((buffer (gdb-get-buffer (car elt))))
                           (if buffer
                               (cons buffer (car elt))
                             nil)))
                       gdb-buffer-rules-assoc)))
        ;; Use 'car' to avoid the minibuffer window here.
        (tree (car (window-tree))))
    (setq gdb-frame-saved-windows
          (gdb--rewrite-window-tree tree
                                    (if (consp tree) (nth 0 tree) nil)
                                    (lambda (window)
                                      (gdb--save-window-mapper buffer-map
                                                               window))))))

;;; gdb-frame.el ends here

[Nick Roberts]

 > > Dedicating windows gives some control over window configuration.  Even if
 > > gdb-many-windows is nil the user might choose to display buffers manually
 > > that give a similar configuration to when it is t.
 >
 > Well, if it is nil, the user obviously wants to control windows as he
 > wants, at least that's the reason why I toggle off many windows from
 > time to time.

He probably knows which buffers he wants in which windows but I'm not sure if
he knows how to put them there.


 > > In order for me to accommodate your pattern of use, you need to provide a
 > > recipe that illustrates the problem.
 >
 > In this case only one window was displayed (the stack trace).  No other
 > emacs frame on the "virtual desktop" (or whatever this is called).

I still can't reproduce this, or Miles' problem whrere gdb-ui will hide the gdb
buffer as a side-effect of popping up the source buffer (which may be a
consequence of the GUD buffer _not_ being in a dedicated window.


 > >  > Do these windows have to be dedicated?
 > >
 > > Not making them dedicated might fix your specific problem but would surely
 > > cause others.  Currently window placement relies on heuristics and it will
 > > probably always be possible to find a usage pattern where gdb-ui has annoying
 > > behaviour.
 >
 > But why does gdb-ui wants to manage windows in the first place (if "many
 > windows" is nil)?  I don't quite see what it wants to achieve with it and
 > what can't be done with the usual functions (switch-to, display, ...).

OK, I've just tried using gdb-ui without making windows dedicated and not
noticed any degradation in performance.  Maybe dedicating the windows is
historical and isn't needed now windows are split more readily.  It's really
just evolved from my arbitrary personal use.  If you want to submit a patch and
others, e.g., Miles, think it's an improvement, I'll be happy to install
it.

--
Nick                                           http://www.inet.net.nz/~nickrob

[Nick Roberts]

Tom Tromey writes:
 > >> Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
 > >> dedicated window even if `gdb-many-windows' is t.  It just takes to much
 > >> space and makes it hard to look at two source files at the same time.
 >
 > Nick> If it takes up too much room why use a separate buffer?  If you need a
 > Nick> separate buffer, why not put it in another frame?
 >
 > The effect I would like is to have a single, screen-filling "gdb UI"
 > frame show up when I start debugging, and have it go away when I
 > finish debugging.  And, I'd like to be able to arrange the windows in
 > this frame the way I like.

Killing the GUD buffer kills the associated buffers.  Maybe that's not obvious
but it is mentioned in the manual.

 > The "one frame" approach is vaguely reminiscent of an Eclipse
 > perspective.  FWIW I think it is reasonable for some people to want
 > multiple frames and some to want a single frame.
 >
 > To achieve this, a few changes are needed.  First, Emacs needs a new
 > way to maximize a frame so it doesn't overshadow the panel.  Second,
 > gdb-ui needs some window layout code.

I'm not sure what you mean.  Emacs appears maximise a frame like any other
application and the (Gnome) planel always remains visible for me.

 > >> BTW, how about some key bindings to move around / display the gdb-ui
 > >> windows?
 >
 > Nick> It would be nice to be able to move the buffers around like
 > Nick> views in Eclipse but that would be a substantial task.  Emacs 23
 > Nick> has tabs in the header line of some buffers.  Do you have any
 > Nick> concrete ideas?
 >
 > A while back I wrote the appended.  It isn't perfect, but the idea is
 > that you can rearrange the windows by hand, then save the state.
 > Then, next time, M-x gdb-frame-restore-windows will use this window
 > layout instead of the built-in one.

Yes it would be nice to have something like this, although I generally don't
want to start with the same window arrangement that I finished with in the
previous sessiion.  Whenever possible I recompile and stay in the same session
and that way I keep breakpoints, command history etc.


 > A few unimplemented refinements: have gdb-ui do this automatically,
 > save the window configuration, and allow multiple "source" windows w/
 > LRU replacement.

For the source window I think this would need to save the source buffer and use
gdb-display-source-buffer.

--
Nick                                           http://www.inet.net.nz/~nickrob

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@...> writes:

Tom> To achieve this, a few changes are needed.  First, Emacs needs a
Tom> new way to maximize a frame so it doesn't overshadow the panel.

Nick> I'm not sure what you mean.  Emacs appears maximise a frame like
Nick> any other application and the (Gnome) planel always remains
Nick> visible for me.

Try:

(modify-frame-parameters nil '((fullscreen . fullboth)))

For me this covers the whole screen.  I reported this last year
sometime ... Emacs needs a new fullscreen mode that respects the fd.o
standard here.  (It needs the current mode for presentation apps.)

Nick> Yes it would be nice to have something like this, although I
Nick> generally don't want to start with the same window arrangement
Nick> that I finished with in the previous sessiion.  Whenever
Nick> possible I recompile and stay in the same session and that way I
Nick> keep breakpoints, command history etc.

Different strokes...

Tom

[Tomas Zerolo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jul 07, 2008 at 08:40:59AM -0600, Tom Tromey wrote:

[...]

> (modify-frame-parameters nil '((fullscreen . fullboth)))
>
> For me this covers the whole screen.  I reported this last year
> sometime ... Emacs needs a new fullscreen mode that respects the fd.o
> standard here.  (It needs the current mode for presentation apps.)

Yes, pleeeease :-)

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIckDPBcgs9XrR2kYRAhwlAJ9ubOYK1OmEudl1RUwstGFTBEP7mACfXfj/
VbsvyskLlvLLshSu/zOM4xQ=
=FPG0
-----END PGP SIGNATURE-----

[David Hansen-2]

On Mon, 07 Jul 2008 08:40:59 -0600 Tom Tromey wrote:

>>>>>> "Nick" == Nick Roberts <nickrob@...> writes:
>
> Tom> To achieve this, a few changes are needed.  First, Emacs needs a
> Tom> new way to maximize a frame so it doesn't overshadow the panel.
>
> Nick> I'm not sure what you mean.  Emacs appears maximise a frame like
> Nick> any other application and the (Gnome) planel always remains
> Nick> visible for me.
>
> Try:
>
> (modify-frame-parameters nil '((fullscreen . fullboth)))
>
> For me this covers the whole screen.  I reported this last year
> sometime ... Emacs needs a new fullscreen mode that respects the fd.o
> standard here.  (It needs the current mode for presentation apps.)

Just a bit curious, isn't it the window managers job to put the window
into full screen?  At least that's the way I do it.  But I don't have a
panel or stuff, so maybe these problems don't exits here at all.

David

[Lennart Borgman (gmail)]

David Hansen wrote:

> On Mon, 07 Jul 2008 08:40:59 -0600 Tom Tromey wrote:
>
>>>>>>> "Nick" == Nick Roberts <nickrob@...> writes:
>> Tom> To achieve this, a few changes are needed.  First, Emacs needs a
>> Tom> new way to maximize a frame so it doesn't overshadow the panel.
>>
>> Nick> I'm not sure what you mean.  Emacs appears maximise a frame like
>> Nick> any other application and the (Gnome) planel always remains
>> Nick> visible for me.
>>
>> Try:
>>
>> (modify-frame-parameters nil '((fullscreen . fullboth)))
>>
>> For me this covers the whole screen.  I reported this last year
>> sometime ... Emacs needs a new fullscreen mode that respects the fd.o
>> standard here.  (It needs the current mode for presentation apps.)
>
> Just a bit curious, isn't it the window managers job to put the window
> into full screen?  At least that's the way I do it.  But I don't have a
> panel or stuff, so maybe these problems don't exits here at all.

Yes, I think at least on w32 it is the window manager's job.

[Tom Tromey]

>>>>> "David" == David Hansen <david.hansen@...> writes:

David> Just a bit curious, isn't it the window managers job to put the window
David> into full screen?  At least that's the way I do it.  But I don't have a
David> panel or stuff, so maybe these problems don't exits here at all.

It is nice to be able to do it programmatically as well.  AIUI, both
Gnome and KDE conform to a spec that enables this possibility for
client apps.

Tom

[Lennart Borgman (gmail)]

Tom Tromey wrote:
>>>>>> "David" == David Hansen <david.hansen@...> writes:
>
> David> Just a bit curious, isn't it the window managers job to put the window
> David> into full screen?  At least that's the way I do it.  But I don't have a
> David> panel or stuff, so maybe these problems don't exits here at all.
>
> It is nice to be able to do it programmatically as well.  AIUI, both
> Gnome and KDE conform to a spec that enables this possibility for
> client apps.


That is of course possible on w32 too. You tell the window manager to
maximize the window. The window manager knows the correct size and
position for a maximized window.

[Lennart Borgman (gmail)]

Stephen J. Turnbull wrote:

> David Hansen writes:
>
>  > Just a bit curious, isn't it the window managers job to put the window
>  > into full screen?
>
> It is, in fact if you are running a window manager under X11 it's the
> only way to do it.  The window manager will simply clip the client's
> window to what it has decided to allow.
>
> The problem is that there are many options regarding what "maximize"
> means:
>
> 1.  Is it in response to the user (eg, clicking a maximize button on
>     the frame) or the client (eg, obeying a "start me maximized"
>     resource)?
> 2.  Which dimensions are maximized (horizontal, vertical, both)?
> 3.  Are window decorations maintained for the maximized window?
> 4.  Are window and session manager widgets (panel, taskbar, etc)
>     allowed to be covered?
>
> Distinction (1) is essential to usability; you need to be able to do
> both.  Many users don't care so much about flexibility in areas (2),
> (3), and (4), but others do.  One of the projects of freedesktop.org
> (somebody referred to that as "fd.o") is to provide a standard
> protocol for any client and window manager that allows all of these
> parameters to be set in a flexible way.

Another essential thing is the placement of the maximized window.

[Stephen J. Turnbull]

David Hansen writes:

 > Just a bit curious, isn't it the window managers job to put the window
 > into full screen?

It is, in fact if you are running a window manager under X11 it's the
only way to do it.  The window manager will simply clip the client's
window to what it has decided to allow.

The problem is that there are many options regarding what "maximize"
means:

1.  Is it in response to the user (eg, clicking a maximize button on
    the frame) or the client (eg, obeying a "start me maximized"
    resource)?
2.  Which dimensions are maximized (horizontal, vertical, both)?
3.  Are window decorations maintained for the maximized window?
4.  Are window and session manager widgets (panel, taskbar, etc)
    allowed to be covered?

Distinction (1) is essential to usability; you need to be able to do
both.  Many users don't care so much about flexibility in areas (2),
(3), and (4), but others do.  One of the projects of freedesktop.org
(somebody referred to that as "fd.o") is to provide a standard
protocol for any client and window manager that allows all of these
parameters to be set in a flexible way.

[Miles Bader-4]

Nick Roberts <nickrob@...> writes:
> I still can't reproduce this, or Miles' problem whrere gdb-ui will hide the gdb
> buffer as a side-effect of popping up the source buffer (which may be a
> consequence of the GUD buffer _not_ being in a dedicated window.
...
> OK, I've just tried using gdb-ui without making windows dedicated and not
> noticed any degradation in performance.  Maybe dedicating the windows is
> historical and isn't needed now windows are split more readily.  It's really
> just evolved from my arbitrary personal use.  If you want to submit a patch and
> others, e.g., Miles, think it's an improvement, I'll be happy to install
> it.

I'm not sure what's going on really -- the window doesn't seem to be
dedicated.  I'm not sure if I am using the same setup as other people, I
just say "M-x gdb" to invoke gdb, and get, initially, just a single
*gud...* buffer.

Anyway the problem is when the frame contains only a single window, with
the *gud...* buffer; if I do M-: (window-dedicated-p (selected-window)),
the result is nil.  So, at that point, if I type in, e.g., "up RET" to
the gdb prompt, naturally it tries to display the source code of the
new frame -- but the source-code buffer _replaces_ the *gud...* buffer
in the single window, instead of splitting the frame!

It _doesn't_ seem to happen if use "emacs -Q", so I guess it's some
setting, but I'm not sure what (I don't set any gud- or gdb- variables,
and the same/special-foo variables all seem normal).

The "immediate" cause seems to be that in the variable
`gdb-source-window' is different; in my normal (non-"-Q") emacs,
gdb-source-window seems to often point to the actual window being used
to display the *gud...* buffer; I guess this causes the problem.

-Miles

--
Electricity, n. The cause of all natural phenomena not known to be caused by
something else.

[Miles Bader-4]

I wrote:

>> I still can't reproduce this, or Miles' problem whrere gdb-ui will hide the gdb
>> buffer as a side-effect of popping up the source buffer (which may be a
>> consequence of the GUD buffer _not_ being in a dedicated window.
> ...
>> OK, I've just tried using gdb-ui without making windows dedicated and not
>> noticed any degradation in performance.  Maybe dedicating the windows is
>> historical and isn't needed now windows are split more readily.  It's really
>> just evolved from my arbitrary personal use.  If you want to submit a patch and
>> others, e.g., Miles, think it's an improvement, I'll be happy to install
>> it.
>
> I'm not sure what's going on really -- the window doesn't seem to be
> dedicated.  I'm not sure if I am using the same setup as other people, I
> just say "M-x gdb" to invoke gdb, and get, initially, just a single
> *gud...* buffer.

Ah, actually I can reproduce it with "emacs -Q":

  (1) start a gdb session in emacs, and hit a breakpoint or something so
      that gdb pops up the source in another window (splitting the frame)

  (2) Switch to the source window with "C-x o"

  (3) Delete the other [*gud...*] window with "C-x 1"

  (4) Switch back to the *gud...* buffer using "C-x b *gud...* RET"

  (5) Try to pop up the source buffer again using a gdb command, e.g.,
      just "frame RET".

*bang*, *gdb...* buffer disappears, source buffer is only ting
displayed... :-(

-Miles

--
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"