Re: gdb-ui, dedicated windows

[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