unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: David Hansen <david.hansen@gmx.net>
Cc: emacs-devel@gnu.org
Subject: Re: gdb-ui, dedicated windows
Date: Sat, 5 Jul 2008 22:02:29 +1200	[thread overview]
Message-ID: <18543.18102.11098.763936@kahikatea.snap.net.nz> (raw)
In-Reply-To: <87zlowwyn1.fsf@localhorst.mine.nu>

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

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

In order for me to accommodate your pattern of use, you need to provide a
recipe that illustrates the problem.

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

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.

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


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


-- 
Nick                                           http://www.inet.net.nz/~nickrob




  reply	other threads:[~2008-07-05 10:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-05  7:58 gdb-ui, dedicated windows David Hansen
2008-07-05 10:02 ` Nick Roberts [this message]
2008-07-05 10:52   ` David Hansen
2008-07-07  4:38     ` Nick Roberts
2008-07-08  7:06       ` Miles Bader
2008-07-08  7:18         ` Miles Bader
2008-07-08 23:39           ` Nick Roberts
2008-07-08 23:46             ` Miles Bader
2008-07-09 10:47               ` Nick Roberts
2008-07-15 13:37                 ` Miles Bader
2008-07-15 21:50                   ` Nick Roberts
2008-07-15 23:43                     ` Miles Bader
2008-07-05 14:04   ` Miles Bader
2008-07-05 16:11   ` Tom Tromey
2008-07-07  5:20     ` Nick Roberts
2008-07-07 14:40       ` Tom Tromey
2008-07-07 16:14         ` tomas
2008-07-07 19:33         ` David Hansen
2008-07-07 19:47           ` Lennart Borgman (gmail)
2008-07-07 20:01           ` Tom Tromey
2008-07-07 20:09             ` Lennart Borgman (gmail)
2008-07-07 23:11           ` Stephen J. Turnbull
2008-07-07 23:03             ` Lennart Borgman (gmail)
2008-07-08 16:02         ` James Cloos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18543.18102.11098.763936@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=david.hansen@gmx.net \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).