Re: Ongoing bsh interface problem

On Mon, 13 Mar 2006, Martin Schwamberger wrote:
> ...
> But anyway, I think there is an easier solution:
> JDEE initializes the class list lazily. This means the search takes place 
> when the user requests the class list the first time.
> Unfortunately, the list update method does not leverage this feature.
> This could easily be fixed.
> Together with the classpath check, the deferred update would at least 
> mitigate the problem.
> Your home directory would only be scanned if it appeared in the
> classpath *and* you called a function that relies on the class list
> (e.g. jde-import-*).
> What do you think?

Well, you're the expert and I'm just a user here, so my 
understanding of JDEE's inner workings is pretty vague. 
But I would guess that "compile" is a function that relies 
on the class list, and for this discussion we can count 
on it being called, so the lazy loading would seem at best 
to defer the problem.

There are a lot of classpaths involved in JDEE, I am 
presuming by "classpath" you mean a user-specified project 
class path, and by "classpath check" you mean your previous 
suggestion:

       If the directory of the class being compiled does not appear in
       the classpath, there should be no need for updating the class
       list.  The JDEE java method ProjectClasses.reloadClasses(String
       classPathEntry) could just ignore the reload request if
       classPathEntry cannot be found in this.classPath.

(where "directory" means "destination directory").  My concern is when
I'm compiling Test.java in my home directory without specifying any
classpath or destination directory.  Currently this seems to be
impossible.  If your suggestion would make that possible, then I'm a
happier camper.  I am not happy with any scenario in which JDEE locks
up Emacs while doing a system-wide search I have not explicitly asked
it to do.

Cheers,
Glenn