Paul,
I think this is good, but I am not sure at what point the debug point is
"confirmed".
I use JDE mainly to debug servlets and store breakpoints in the prj file.
When I open a java file with stored breakpoints, the breakpoints show yellow.
However, when I attach to a running Tomcat, unless I "reconfirm" the
breakpoint manually (by setting it again on the alreay highlighted lines) the
debugger does not stop there. I guess the debuger server needs to be told
told "manually" about those breakpoints. Two things would be great to have:
1. Store the breakpoints automatically, so they persist across emacs exiting.
2. When I attach the debugger to the debug server on a host, all the
currently set breakpoints would be automatically set (confirmed?) (again, I
guess the debug server would need to be told automatically about the
breakpoints)
Thanks, Milan
On December 9, 2001 11:28 pm, you wrote:
> Hi All,
>
> One of the issues regarding the jdb and
> JDEbug set breakpoint commands is that
> they really don't set breakpoints. They
> request them. The JDE allows you to "set"
> (i.e., request) a breakpoint when the
> debugger is not running. Both JDEbug and
> jdb allow you to set ("request") a breakpoint
> when a class is not loaded and thus when
> there is no way for the debugger to know
> if the breakpoint is valid. In this case,
> the debugger defers setting the breakpoint
> until the class loads. Currently the JDE's
> breakpoint highlight does not allow you
> to distinguish between a "provisional"
> breakpoint, i.e., one that has been
> requested but not confirmed, and one that is
> actually set. The breakpoint is marked
> with a yellow highlight in either case.
> This can be confusing. So I'm thinking
> of using two colors to highlight lines
> where breakpoints are set. A yellow
> highlight would indicate that the
> breakpoint has been requested but not
> confirmed. A red highlight would indicate
> a confirmed breakpoint.
>
> Please let me know if you find any problems
> with this approach or have a better idea.
>
> Regards,
>
> Paul
