At 02:20 PM 3/28/00 +0200, you wrote:
>Hi!
>
>> >* I started my debug session in the buffer Foo.java which then took me
>> >to Bar.java. I got an exception which was printed to stdout, so I
>> >selected JDebug -> Show Buffer -> CLI. Then the buffer arrengement
>> >reverted back so I was in the Foo.java buffer again with the correct CLI
>> >buffer.
>> >
>> 
>> Yes. This is a bug that I haven't gotten around to fixing yet.
>>
>I just thought of one more thing. Wouldn't it be much easier if each JDebug
>buffer/window was in its own frame (or that all JDebug buffers/windows were
>colocated in the same frame)?
>
>For instance. I usually split my emacs frame in two vertical windows (i.e. two
>80 character wide buffers next to each other), and then I split those in 
>several
>horisontal windows. When I choose JDE -> Debug App, the JDebug sets its 
>standard
>window configuration, which assumes that you don't split buffers/windows as I
>do, thus I loose my window configuration each time I debug.
>
>It is quite complicated to handle the window configurations (saving previous
>state, or whatever), if you want to impose some kind of standard
configuration.
>I think the easy way out of that mess is to simply use frames for the JDebug
>buffers.
>
>Perhaps the behaviour should be configurable? I guess it is virtually 
>impossible
>to have some kind of solution which everyone agrees upon...
>

I spent a lot of time thinking about how to do window management and could
not come up with a solution that I thought would meet everybody's needs. I
finally just decided to go with the basic three pane configuration as this
is a natural extension of the standard two-pane configuration used for
compiling, running, and debugging apps in Emacs. The user can than use
Emacs' extensive set of window management commands to rearrange windows to
suit their needs. For example, it's trivial to pop any buffer into its own
frame from the Emacs command line.

I of course am always eager to hear suggestions about alternative ways to
deal with these kinds of design problems.

Regards,

- Paul

Reply via email to