Re: Window/buffer management in gdb-ui

[Stefan Monnier]

>> > gdb-display-buffer was part of gdba.el. It did extra things like not
>> > replace the window with the GUD buffer with new content. Perhaps
>> > display-buffer could be used but now I make new gdb-related windows
>> > dedicated here
>> 
>> 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.

Well, I know what it does.  My question had to do with the end goal:
"protect the contents of a window" is not very clear.  Which scenario are
you trying to avoid?

> 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.

The special-buffer-regexp thingy is used at a place where the window has
just been created.  The problem is in gdb-display-buffer where you reuse
a preexisting window (the one returned by get-lru-window) which might
display any random buffer.

Dedicated windows are not a problem in and of themselves (most of my
windows are dedicated).  The problems come when you take a non-dedicated
window which the user used for some purpose and "you" suddenly hijack it by
making it dedicated.  So I suggest to change gdb-display-buffer further and
only call set-window-dedicated-p in the `must-split' branch (i.e. only call
it on the window you've just created):

-- gdb-ui.el    25 nov 2004 10:24:41 -0500      1.34
++ gdb-ui.el    25 nov 2004 23:16:19 -0500      
@@ -1608,8 +1608,8 @@
               (cur-size (window-height largest))
               (new-size (and size (< size cur-size) (- cur-size size))))
          (setq answer (split-window largest new-size))
-         (set-window-buffer answer buf)))
-    (set-window-dedicated-p answer t)
+         (gdb-set-window-buffer answer buf))
+          (set-window-dedicated-p answer t))
       answer)))
 
 (defun gdb-display-source-buffer (buffer)

You could almost reuse gdb-set-window-buffer on those two new lines, BTW.

>> > It doesn't seem to interfere with the setups that I'm thinking of, so I've
>> > installed these changes. I don't really know what the change below does
>> > but gdb-frame-breakpoints-buffer is one of a family of commands accessible
>> > from the menubar (GUD->GDB Frames->...) so should these be changed also?
>> 
>> I think so, yes.
>> What it does is that it allows users to specify the behavior they want in
>> special-display-regexp or special-display-buffer-names.

> I've changed these (apart from gdb-frame-gdb-buffer because the gud buffer
> is covered by same-window-regexps). I've removed the menubar and minibuffer
> from the resulting frames using special-display-frame-alist (maybe this
> make no difference with your setup).

Indeed ;-)

> I tried not to select the buffer by using display-buffer instead of
> pop-to-buffer but it still seems to select it anyway (Is this a bug in
> Emacs?).

I'm not sure whether it's a bug or not, but I've seen this behavior.
Maybe you should report it for others to judge whether it's a bug or not.
You can of course wrap the whole thing inside `with-current-buffer' if
that's a problem (I seem to remember doing exactly that in some code, maybe
for PCL-CVS?).


        Stefan