emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gdb-ui, dedicated windows


From: David Hansen
Subject: Re: gdb-ui, dedicated windows
Date: Sat, 05 Jul 2008 12:52:00 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]