Re: Window/buffer management in gdb-ui

[Kim F. Storm]

Nick Roberts <address@hidden> writes:

>  > Why do you make the window dedicated.  I think a window should only be made
>  > dedicated when it's created.  If you take a preexisting window that
>  > potentially shows any buffer (even unrelated to GDB-UI) and make it
>  > dedicated it'll screw things up sooner or later.
>
> Its the only way, that I know of, to protect the contents of a window. I think
> I only make the windows dedicated *after* I put the gdb-related stuff in
> them. I take your point that dedicated windows can be a nuisance. Thats why I
> try to undedicate any source buffers left after a debug session. The
> special-frames-regexp seems to make the window dedicated indirectly and so, to
> be honest, I can't see how this differs, in practice, from what I had before.

Yesterday, I was debugging some redisplay oriented problems, and at some point
the dedicated windows stuff started to get really into the ways.

I had this window setup:

+----------------+
|  *gud-emacs*   |
|                |
|                |
|----------------|
|     xdisp.c    |
|                |
|                |
+----------------+

I stepped into a function in xfaces.c, and now it split windows like this:

+----------------+
|  *gud-emacs*   |
|----------------|
|    xfaces.c    |
|----------------|
|     xdisp.c    |
|                |
|                |
+----------------+

I'm used to gdb replacing the xdisp.c window with the xfaces.c window when
I single step like that.

I got a little confused, so I enlarged xdisp.c window to fill the screen:

+----------------+
|     xdisp.c    |
|                |
|                |
|                |
|                |
|                |
|                |
+----------------+

Said, oops, and tried to show the *gud-emacs* buffer instead, and go
bitten:  xdisp.c is a dedicated buffer (or whatever the error was).

As an effect, the *gud-emacs* instead popped up in a different frame.
I rarely use frames like that, so it was quite unexpected - and unwanted!

+----------------+
|     xdisp.c    |
|+---------+     |
|| *gud*   |     |
||         |     |
|+---------+     |
|                |
|                |
+----------------+

Then at some point after that, things started to get lots of errors 
in display_buffer complaining about getting #<window on xdisp.c>
as arg or some such.

The following patch fixes that problem, but I'm not sure that
is what you intended:

Index: lisp/progmodes/gdb-ui.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/gdb-ui.el,v
retrieving revision 1.35
diff -u -r1.35 gdb-ui.el
--- lisp/progmodes/gdb-ui.el    25 Nov 2004 23:51:18 -0000      1.35
+++ lisp/progmodes/gdb-ui.el    26 Nov 2004 10:09:54 -0000
@@ -1595,7 +1595,7 @@
   (let ((answer (get-buffer-window buf 0))
        (must-split nil))
     (if answer
-       (display-buffer answer)         ;Raise the frame if necessary.
+       (display-buffer buf)            ;Raise the frame if necessary.
       ;; The buffer is not yet displayed.
       (pop-to-buffer gud-comint-buffer)        ;Select the right frame.
        (let ((window (get-lru-window)))



I haven't rechecked whether your latest changes have fixed any of this,
but although I also got a little annoyed by the *gud* buffer disappearing
from time to time, the current behaviour with dedicated source windows
is VERY annoying.   

Perhaps it would be better to have only one dedicated source window at
a time (the one where the overlay-arrow is).


-- 
Kim F. Storm <address@hidden> http://www.cua.dk