#3 Fix for jdb source code pointer problem

[Paul Kinnucan]

Carlos Konstanski [ckonstanski@pippiandcarlos.com]

I prefer jdb over jdebug because jdb has enough functionality for 99% of my debugging needs, and less gizmos and knobs in the way. (Jdebug is indespensible for some situations.) But there is a bug that affects code-stepping in jdb. You can step through code, but the pointer in the left gutter of the source buffer cannot track the current line because of a stringp type error. The error occurs during the routine for finding the source buffer. Here's the quick fix:

In jde-util.el, the function (jde-find-class-source-file) has these as the first 2 lines:

(let* ((verified-name (jde-parse-class-exists class))
(outer-class (jde-remove-inner-class verified-name))

This would be good if (jde-parse-class-exists) returned a string, but it returns a boolean instead. The call to (jde-remove-inner-class) throws a '(type stringp nil) error as a result. Change the code to:

(let* ((verified-name (jde-parse-class-exists class))
(outer-class (jde-remove-inner-class class))

`class' is the passed-in string argument to (jde-find-class-source-file). This is the quick fix. It seems to work like it needs to. But this makes the logical flow in this function less than ideal. If we're going to call
(jde-parse-class-exists) to validate the input, we should do something with that validation before doing more stuff, or fail gracefully.
Something like:

(if (jde-parse-class-exists class)
(let ((outer-class (jde-remove-inner-class class)))
(do-stuff)
...)
(signal-no-src-found class))

I will try to spend some time refactoring this function and submitting it for review.