[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GDB-UI and multiple frames
From: |
Miles Bader |
Subject: |
Re: GDB-UI and multiple frames |
Date: |
Sat, 3 Apr 2004 19:13:01 -0500 |
User-agent: |
Mutt/1.3.28i |
On Sat, Apr 03, 2004 at 02:05:40PM -0500, Stefan Monnier wrote:
> 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.
Yup. Among other things, some people may use it in a `mouse clickey' manner
-- use the toolbar buttons or something to do most operations -- and others
(like me, and people who are accustomed to the old gud-mode) use it via the
gudb command-line.
In the latter cases it's usually a very bad idea to delete the gdb command
window. gdb-ui used to do this fairly often; nowdays it seems better but
still does so occasionally (usually when one of the `minor windows' like
program I/O, pops up).
> > 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?
I think that might be handy: For instance, for command-line users, the
command-line window should be `important'. Now that program I/O has it's own
buffer, sometimes I get that buffer popping up (and hiding the command line
window!) for programs where I don't care about the program I/O, and I'd
really like to be able to tell gud-mode `I/O is not important, don't bother
to pop up its window'. Maybe gud-mode should pop up a buffer (when its
content changes) only if doing so doesn't hide a more important buffer.
The big problem AFAICS is what interface to use for setting such priorities.
-Miles
--
We have met the enemy, and he is us. -- Pogo
Re: GDB-UI and multiple frames, Richard Stallman, 2004/04/04