Window/buffer management in gdb-ui

Window/buffer management in gdb-ui

[Stefan Monnier]

The window-/buffer management in gdb-ui is not working well in my setup.
And the code in gdb-ui looks pretty frightening.  E.g. things like:

   (defun dedicated-switch-to-buffer (name)
     (set-window-dedicated-p 
      (get-buffer-window
       (switch-to-buffer name)) t))

make me cringe:
- messes up the namespace
- it changes the currently selected window and makes it dedicated
  (because we know that (get-buffer-window (switch-to-buffer name))
   is always equal to (selected-window))

I understand that maybe my setup is not representative, but maybe if you
could describe what behavior you're trying to get, I can help you come up
with a way to code it that doesn't plays nicely in my situation.

I.e. what is the behavior you're trying to get.  You can describe it with
a mix of description of how *you* want it plus some examples of problematic
behaviors you'd like to avoid (i.e. bug-reports).

As for my own setup, I use 1 buffer per frame and 1 frame per buffer with
a separate dedicated minibuffer.  In my setup, any code that uses
`switch-to-buffer' is a pain in the rear.


        Stefan

Window/buffer management in gdb-ui

[Nick Roberts]

 > The window-/buffer management in gdb-ui is not working well in my setup.
 > And the code in gdb-ui looks pretty frightening.  E.g. things like:
 > 
 >    (defun dedicated-switch-to-buffer (name)
 >      (set-window-dedicated-p 
 >       (get-buffer-window
 >        (switch-to-buffer name)) t))
 > 
 > make me cringe:invo
 > - messes up the namespace

I know that standard practice is to prefix such functions, in general, with
gdb but this isn't really a gdb-related function. I felt that the occasional
violation i.e one for the whole of gdb-ui.el, would not cause a problem, in
practice, and may help prevent duplication with locally defined functions
performing the same task.

 > - it changes the currently selected window and makes it dedicated
 >   (because we know that (get-buffer-window (switch-to-buffer name))
 >    is always equal to (selected-window))

Its only used when gdb-ui sets up/restores the windows.

 > I understand that maybe my setup is not representative, but maybe if you
 > could describe what behavior you're trying to get, I can help you come up
 > with a way to code it that doesn't plays nicely in my situation.
 >
 > I.e. what is the behavior you're trying to get.  You can describe it with
 > a mix of description of how *you* want it plus some examples of problematic
 > behaviors you'd like to avoid (i.e. bug-reports).

I noticed two things. Firstly, when the user displays a gdb-related buffer in
another window (M-x gdb-display-BUFFERTYPE-buffer or from the menubar,
GUD->GDB-Windows->...) it can replace an existing buffer that the user wants
to remain visible. These changes ensure that, in this case, a gdb-related
buffer is split to provide space for the new buffer. Secondly, if the user
wants to do something different in between debugging, visit info or list
buffers, for example, it is best for that buffer to appear in a separate
frame.

Its a `work in progress', I haven't thought it through yet. Since the "feature
freeze" could extend to infinity, I figured I'd have enough time to put it
right. Also, as its been quiet recently, I thought maybe everyone was using
"-fullname". I guess this is one way of finding out!

 > As for my own setup, I use 1 buffer per frame and 1 frame per buffer with
 > a separate dedicated minibuffer.  In my setup, any code that uses
 > `switch-to-buffer' is a pain in the rear.

You never have split windows? How do you arrange that? What is a "separate
dedicated minibuffer"?


  Nick

Re: {Spam?} Window/buffer management in gdb-ui

[Stefan Monnier]

>> - messes up the namespace

> I know that standard practice is to prefix such functions, in general, with
> gdb but this isn't really a gdb-related function. I felt that the occasional
> violation i.e one for the whole of gdb-ui.el, would not cause a problem, in
> practice, and may help prevent duplication with locally defined functions
> performing the same task.

No, that's not how it works.  You should define it as gdb-<something> and/or
lobby on emacs-devel to add it to some global file like subr.el.

>> - it changes the currently selected window and makes it dedicated
>> (because we know that (get-buffer-window (switch-to-buffer name))
>> is always equal to (selected-window))

> Its only used when gdb-ui sets up/restores the windows.

Hmm... I don't understand.
First, there's the problem of using get-buffer-window instead of
selected-window (maybe it's not a problem, but I find to be confusing).
Then there's the problem of using switch-to-buffer which forcefully hides
the previously displayed buffer.  And finally there's the problem of marking
as dedicated a window that already existed as non-dedicated (and had thus
a different purpose).

Are you telling me that you always know for sure that the buffer previously
displayed is of no interest to the user and can safely be hidden and the
window can of course be reused?  Is it because the window was just created
(and thus displays a random buffer)?

>> I understand that maybe my setup is not representative, but maybe if you
>> could describe what behavior you're trying to get, I can help you come up
>> with a way to code it that doesn't plays nicely in my situation.
>> 
>> I.e. what is the behavior you're trying to get.  You can describe it with
>> a mix of description of how *you* want it plus some examples of problematic
>> behaviors you'd like to avoid (i.e. bug-reports).

> I noticed two things. Firstly, when the user displays a gdb-related buffer in
> another window (M-x gdb-display-BUFFERTYPE-buffer or from the menubar,
GUD-> GDB-Windows->...) it can replace an existing buffer that the user wants
> to remain visible. These changes ensure that, in this case, a gdb-related
> buffer is split to provide space for the new buffer. Secondly, if the user
> wants to do something different in between debugging, visit info or list
> buffers, for example, it is best for that buffer to appear in a separate
> frame.

> Its a `work in progress', I haven't thought it through yet. Since the "feature
> freeze" could extend to infinity, I figured I'd have enough time to put it
> right. Also, as its been quiet recently, I thought maybe everyone was using
> "-fullname". I guess this is one way of finding out!

This assumes much too much already.  Please start from the beginning and
describe to me the behavior you (want to) see in general when you use
GDB-UI: where is displayed which buffer (both source buffers and GDB-UI's
own buffers), when, etc...

>> As for my own setup, I use 1 buffer per frame and 1 frame per buffer with
>> a separate dedicated minibuffer.  In my setup, any code that uses
>> `switch-to-buffer' is a pain in the rear.

> You never have split windows?

Very rarely.

> How do you arrange that?

(setq pop-up-frames t)

> What is a "separate dedicated minibuffer"?

A special frame (typically 1-line tall) that has no window other than
a mini-window that displays a minibuffer (i.e. the frame-parameter
`minibuffer' is set to `only').  The other frames have no
mini-window and use that special frame when they need an echo area or
a minibuffer (the frame-parameter `minibuffer' is set to nil).


        Stefan

Re: {Spam?} Window/buffer management in gdb-ui

[Nick Roberts]

 > No, that's not how it works.  You should define it as gdb-<something> and/or
 > lobby on emacs-devel to add it to some global file like subr.el.

I've renamed it gdb-set-window-buffer.

How about the function, kill-this-buffer, in menu-bar.el?  Would files.el
be a more logical place for it?


   Nick

Re: {Spam?} Re: {Spam?} Window/buffer management in gdb-ui

[Stefan]

>> No, that's not how it works.  You should define it as gdb-<something> and/or
>> lobby on emacs-devel to add it to some global file like subr.el.

> I've renamed it gdb-set-window-buffer.

Thank you.

> How about the function, kill-this-buffer, in menu-bar.el?  Would files.el
> be a more logical place for it?

It doesn't matter quite as much since menu-bar is also preloaded.
But yes: it should probably be moved to simple.el.


        Stefan

Re: Window/buffer management in gdb-ui

[Kai Grossjohann]

Nick Roberts <nickrob@snap.net.nz> writes:

> I know that standard practice is to prefix such functions, in
> general, with gdb but this isn't really a gdb-related function. I
> felt that the occasional violation i.e one for the whole of
> gdb-ui.el, would not cause a problem, in practice, and may help
> prevent duplication with locally defined functions performing the
> same task.

Please don't.  It's been a long time ago, so I don't remember clearly,
but I recall a situation where a package defined a "standard" function
that later caused trouble because it was not quite compatible to the
"real" standard function (which appeared in Emacs after the package
was written).

When the standard function is later added to Emacs, you can always use
defalias on your side to avoid defining a second function.

WDYT?

Kai

Re: Window/buffer management in gdb-ui

[Kai Grossjohann]

Kai Grossjohann <kai@emptydomain.de> writes:

> Please don't.

I take that back.  Please replace it with `IMVHO'.

I should go to bed...
Kai

Re: Window/buffer management in gdb-ui

[Nick Roberts]

 > But now that I look at the code a bit more closely, I think I see where I'm
 > suffering the most: it's in gdb-display-buffer.  Could you explain to me why
 > `display-buffer' is not doing what you want?

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

 > Also, would it be possible to introduce a variable to prevent displaying the
 > ASM code (when debugging C code, I prefer not to see anything than to be
 > shown a piece of assembly when I'm in the middle of some libc-internal
 > routine)?

Yes, I have thought that too. I'll put it on my TODO list.

 > Here is also a patch that might give a flavor of the direction I'd like to
 > go w.r.t buffer/window management.  Please commit the parts which seem to
 > work in your setup.  They help mine.

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?

 > @@ -1199,9 +1199,8 @@
 >  (defun gdb-frame-breakpoints-buffer ()
 >    "Display status of user-settable breakpoints in a new frame."
 >    (interactive)
 > -  (select-frame (make-frame gdb-frame-parameters))
 > -  (switch-to-buffer (gdb-get-create-buffer 'gdb-breakpoints-buffer))
 > -  (set-window-dedicated-p (selected-window) t))
 > +  (let ((special-display-regexps (append special-display-regexps '(".*"))))
 > +    (pop-to-buffer (gdb-get-create-buffer 'gdb-breakpoints-buffer))))
 >  
 >  (defvar gdb-breakpoints-mode-map
 >    (let ((map (make-sparse-keymap))

 Nick

Re: Window/buffer management in gdb-ui

[Stefan Monnier]

>> But now that I look at the code a bit more closely, I think I see where I'm
>> suffering the most: it's in gdb-display-buffer.  Could you explain to me why
>> `display-buffer' is not doing what you want?

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

>> Also, would it be possible to introduce a variable to prevent displaying the
>> ASM code (when debugging C code, I prefer not to see anything than to be
>> shown a piece of assembly when I'm in the middle of some libc-internal
>> routine)?
> Yes, I have thought that too. I'll put it on my TODO list.

Great minds think alike ;-)

>> Here is also a patch that might give a flavor of the direction I'd like to
>> go w.r.t buffer/window management.  Please commit the parts which seem to
>> work in your setup.  They help mine.

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


        Stefan

Re: Window/buffer management in gdb-ui

[Nick Roberts]

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

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


 Nick

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

Re: Window/buffer management in gdb-ui

[Nick Roberts]

 > 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'm thinking of two modes of operation. Firstly the gdb buffers in separate
frame which I think was working OK. Secondly the gdb buffers in one frame
(either using gdb-many windows or invoking the commands gdb-display-breakpoints
etc separately) which was not so good.

I've tried to get rid of gdb-display-buffer as much as possible so that it
only executes when explicitly invoked through the gdb-display-breakpoints
family.

I've got rid of gdb-view-source etc. The machine code is not juggled
with the source but appears as an unrelated buffer. I don't know what I
was thinking of but there was only one overlay arrow available at the time.

I've only tested it very quickly, its probably a bit flakey.


   Nick

Re: {Spam?} Re: Window/buffer management in gdb-ui

[Stefan Monnier]

>> 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'm thinking of two modes of operation. Firstly the gdb buffers in
> separate frame which I think was working OK. Secondly the gdb buffers in
> one frame (either using gdb-many windows or invoking the commands
> gdb-display-breakpoints etc separately) which was not so good.

That doesn't tell me the scenario(s) you're trying to avoid.


        Stefan

Re: Window/buffer management in gdb-ui

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> 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 <storm@cua.dk> http://www.cua.dk

Re: Window/buffer management in gdb-ui

[Nick Roberts]

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

Try it now. It should behave as before (perhaps a bit better!)

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

I would like the reverse actually: one undedicated window (the source buffer).
At the moment the GUD and the source and, sometimes the other gdb-related
buffers will be undedicated. It means that they might be replaced by new
buffers if they are not in their own frame.


  Nick

Re: Window/buffer management in gdb-ui

[Stefan Monnier]

[ Maybe you know this already, but all your email to me gets flagged as spam
  because of SORBS.  I know SORBS sucks, but I haven't managed to convince
  the sysadmins here and they control the spam filter.  Luckily SPAM is not
  thrown away, but since your email ends up in a separate "spam" folder,
  it's pretty likely that I might overlook some of your messages to me :-( ]

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

> I would like the reverse actually: one undedicated window (the source buffer).
> At the moment the GUD and the source and, sometimes the other gdb-related
> buffers will be undedicated. It means that they might be replaced by new
> buffers if they are not in their own frame.

Actually I think GUD might have better luck if it didn't use get-lru-window.
Instead it could have a "gud-source-window" variable that tries to keep
track of where to display source code.  I know you had something like that
in the past and I bitched about it, so obviously it has to be
done carefully.  How 'bout something along the following lines:

 (defvar gud-source-window nil)

 (defun gud-display-source-buffer (buf)
   (cond
    ((get-buffer-window buf 0)
     ;; If it's already displayed, just raise that window.
     (display-buffer buf))
    ((and gud-source-window (window-live-p gud-source-window))
     ;; If there's a source-window, just use it.
     (select-window gud-source-window)
     ;; Problem here: we don't raise the corresponding frame, but normally
     ;; this window is alongside the gud-comint-buffer, so it should
     ;; hopefully be well within sight.  We'd really want to use
     ;; something like (display-buffer buf 'same-window) instead.
     (switch-to-buffer buf))
    (t
     ;; Else, pop a new window.
     (pop-to-buffer gud-comint-buffer) ; Select a GUD-related frame.
     (let ((pop-up-windows t))
       (setq gud-source-window (display-buffer buf))))))

It'll not follow my own setup's normal behavior, but at least it won't mess
it up.


        Stefan