Re: Ongoing bsh interface problem

Glenn Murray wrote:
> 
> 
> 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?

My description might have been a bit misleading.
The directory I have been taking about is the destination directory.
JDEE's compile finish hook does already restrict the update to the
this directory.
It takes all subdirectories into account because of Java packages.
All imported packages might contain newly compiled files.
The update could be optimized by checking the imports of the source 
file. The check would need to be performed recursively for all updated 
packages.

I would not disable the update if the destination directory is not 
specified. If a class file is accessible via classpath, it should be 
available for JDEE.

BTW, the class list contains all classes found in the classpath of the 
project, not only those belonging to the current project.

Cheers,

Martin

> 
> Cheers,
> Glenn
> 
>