[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GDB-UI and multiple frames
From: |
Stefan Monnier |
Subject: |
Re: GDB-UI and multiple frames |
Date: |
03 Apr 2004 14:05:40 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
> will, in general, confuse GDB-UI. Maybe its poor design but its only
> really a bug if you can propose something better.
Well, I sent my report before coming up with a proposal because I figured
maybe you could help out ;-)
>> - To work around the bug, I do (setq gdb-source-window nil) and next thing
>> you know GUD shows me the assembly code in the window where I had *gud*
>> (that's a poor choice, but it's a strange situation anyway, I won't hold
>> it against gdb-ui for it).
> gdb-source-window is meant to be an internal variable. Thats a bit like
> changing the timing on a car and then complaining that it won't start.
Yes, that's what I meant by "strange situation".
>> I think the notion of gdb-source-window just plain does not fit my usage
>> pattern (I mostly have one frame per buffer). Short of using the old
>> "gdb --fullname" interface, what can I do?
> I guess first of all there should be a consensus as to how the mode
> _should_ work.
I'm not sure such a think exists. Different users use their
tool differently. I think a real issue is that some people like me used to
the Emacs-21.2 M-x gdb behavior will be annoyed by the much more intrusive
buffer/window management, so I think we need a way to make it
less intrusive. This may require config-variables.
> However, I'm not sure that enough people have really used it to reach
> a collective agreement.
I expect that some people will really like it, and others will be
mighty annoyed.
> The problem that I have had in designing it so far, is marking the GUD and
> source buffer as special, so that new buffers do not indvertantly occupy
> their window and so that GDB-UI can track which window the source is in
> (which presumably should be visible at all times once execution has
> started).
I guess we need to first figure out:
- why is it bad for other buffers to occupy a "gud window".
- why do you need to track which window the source is in.
OK, here is something more concrete, although still not a solution:
keep track of `gdb-source-buffer' instead of (or additionally to)
`gdb-source-window'. Since normally you have that
(eq gdb-source-window (get-buffer-window gdb-source-buffer t)), you can
now better react to changes in window-configs.
Also when trying to "show source buffer A", check whether A is already
visible in some window and if so select that window instead of switching
gdb-source-window's content.
> Can some windows be made more important than others/hard to delete/easy to
> redisplay contents when deleted etc?
Why? Which concrete problems are you thinking of?
Stefan
Re: GDB-UI and multiple frames, Richard Stallman, 2004/04/04