From: storm@cua.dk (Kim F. Storm)
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Window/buffer management in gdb-ui
Date: Fri, 26 Nov 2004 11:16:30 +0100 [thread overview]
Message-ID: <m3r7mgkj9d.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <16806.29150.178158.7827@farnswood.snap.net.nz> (Nick Roberts's message of "Fri, 26 Nov 2004 12:59:26 +1300")
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
next prev parent reply other threads:[~2004-11-26 10:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-24 14:59 Window/buffer management in gdb-ui Stefan Monnier
2004-11-24 20:09 ` Nick Roberts
2004-11-24 20:42 ` {Spam?} " Stefan Monnier
2004-11-25 2:30 ` Nick Roberts
2004-11-25 16:26 ` {Spam?} " Stefan
2004-11-24 21:30 ` Kai Grossjohann
2004-11-24 21:39 ` Kai Grossjohann
[not found] ` <jwvpt23arhf.fsf-monnier+emacs@gnu.org>
2004-11-25 2:14 ` Nick Roberts
2004-11-25 16:07 ` Stefan Monnier
2004-11-25 23:59 ` Nick Roberts
2004-11-26 4:21 ` Stefan Monnier
2004-11-26 15:53 ` Nick Roberts
2004-11-26 22:46 ` {Spam?} " Stefan Monnier
2004-11-26 10:16 ` Kim F. Storm [this message]
2004-11-26 15:42 ` Nick Roberts
2004-11-26 22:43 ` Stefan Monnier
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=m3r7mgkj9d.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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).