Re: Ongoing bsh interface problem

On Sat, 11 Mar 2006, Martin Schwamberger wrote:
> Suraj Acharya wrote:
>> On 3/9/06, *Glenn Murray* <[email protected] <mailto:[email protected]>> 
>> wrote:
>>     Hi Suraj,
>>
>>     Indeed it has been broken for some years, it seems my problem is
>>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234416
>>
>>     However this doesn't explain the problem of the long search through my
>>     home directory.  I put the official jde 2.3.5 jars mentioned below in
>>     /usr/share/emacs21/site-lisp/java/lib/ (which is where the bsh
>>     classpath looks for them).  I unset CLASSPATH by
>>
>>     ~/$ export CLASSPATH=
>>
>>     When I open Emacs with Test.java in ~/testemacs/ (which contains only
>>     Test.java) and do C-c C-v C-c,  everything seems to be fine.
>>
>>     However when I open ~/Test.java it compiles OK, but I get an "Updating
>>     class list for /home/glenn" message and it seems to be traversing my
>>     entire home directory: *JDEE bsh* fills up swith "Cannot read contents
>>     of /home/glenn/.wine/dosdevices/z:/usr/..." lines.
>> 
>> Omitting some details the simple answer is that if you put your source
>> files in your home directory, JDE assumes that the entire home
>> directory is part of your project. It tries to traverse it after a
>> compilation so that it can update an internal list of classes for this
>> project.
>> 
>> I can see that this behavior could confuse someone trying out JDE for
>> the first time with a couple of test java files, but I can't think of
>> an easy way to fix it.
>> 
>> We could disable the class list updation if no project file is found
>> but this would trip up people who set up the JDE variables in their
>> emacs start-up files. Does anybody have any ideas?
>
> 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.
>
> HTH,
>
> Martin

If you are interested in an internal list of classes for the 
project, why shouldn't the class list update be restricted 
to the compilation destination directory, and in that case 
only when the user specifies it?

Cheers,
Glenn