I also get annoyed by the same behavior. Sometimes I have two files in the
different java packages but same jde project open in two windows. Just
hitting C-x o (other-window) command costs me around 10-20 seconds on slower
machines. I noticed that this does not happen if I switch across the files
in the same java package.
Is there any way that we can do scanning after something causes the
classpath change or class change like compile action or change of jde
projects or change in the settings by customization rather than when
changing the packages - as it seems to be happening. If some one is
compiling outside of jde - like using make or something they can always
execute some jde function using gnudoit or equivalent to update the classes
after compilation is done.
Functionality provided by bean shell is too valuable to me and as emacs or
OS keeps track of my key strokes even when emacs was busy scanning the
classes, I did not bother to report this annoyance earlier. My solution was
simple - to keep typing without waiting for visual response from emacs.
Just my 2 cents
- Niranjan
-----Original Message-----
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 7:48 AM
To: Jim Snyder
Cc: [EMAIL PROTECTED]
Subject: Re: Rescanning Classes
At 07:44 AM 1/24/01 -0500, you wrote:
>With respect to the jde-auto-parse-enable,
jde-auto-parse-buffer-interval,
>and
>variables jde-auto-parse-max-buffer-size variables, I have mine set as the
>following:
>
>'(jde-auto-parse-enable nil)
>'(jde-auto-parse-buffer-interval 0)
>'(jde-auto-parse-max-buffer-size -1)
>
I don't get it. I explained in the message that you quoted below that the
"scanning" message has nothing to do with parsing. Therefore these
variables have no impact on whether the classpath gets rescanned when you
switch projects. As I explained, the classpath is scanned under the
following circumstance:
Beanshell is on
You just switched projects.
The reason is to ensure that the class list used by the JDE class wizards
reflects the classes used by the current project.
Is this not clear?
- Paul
>What I notice on the following system
>
>Emacs version: 20.7
>JDE version: 2.2.6beta7
>Semantic version: 1.3.1
>Speedbar version: 0.13a
>jsnyder-> uname -a
>SunOS 5.5.1 Generic_103640-31 sun4u sparc SUNW,Ultra-2
>jsnyder->
>
>is that when I edit 2 buffers and make changes, etc, there is no rescanning
>(which is what we want). However, when I invoke BeanShell (C-cC-vC-z) to
find a
>jdk package to automatically put that import at the top of my code, the
>"rescanning classes" gets turned back on.
>
>This also occurs on NT using all the same JDE package versions and emacs
20.6
>(at home).
>
>
>Paul Kinnucan wrote:
>
>> At 11:29 AM 1/10/01 -0500, [EMAIL PROTECTED] wrote:
>> >Can I control when JDE does its "Rescanning classes" function?
>> >
>>
>> Yes. See the info files for the variables jde-auto-parse-buffer-interval
>> and jde-auto-parse-buffer-max-size.
>>
>> Here is the rule that the JDE uses for parsing a buffer:
>>
>> Reparse the buffer jde-auto-parse-buffer-interval seconds after the user
>> has made a change to the buffer and only if the buffer is less that
>> jde-auto-parse-buffer-max-size characters long. Ignore any changes the
user
>> makes while the parse delay timer is ticking. What this means is that if
>> you never change a buffer or the buffer is larger than a size that you
can
>> specify, the JDE never automatically reparses the buffer. If the buffer
is
>> below the max size and you do edit the buffer, the JDE does not
immediately
>> reparse. Instead, it waits for an interval that you can specify. If you
>> make a series of changes, the JDE will still reparse only periodically at
>> the rate that you specify.
>>
>> >The reason that I ask is twofold.
>> >
>> >1. There are times when this is a very expensive operation on my
machine.
>> >2. I have two related projects (one is the primary code, the other is
the
>> >test cases for the primary code) that share the same set of classes but
>> >differ only in compile options. Switching between buffers can trigger
this
>> >"Rescanning classes" function and it can take 5-10 seconds to make the
>> >buffer switch. Very distracting.
>> >
>>
>> This has nothing to do with auto reparse. What you are actually seeing is
>> the JDE updating the list of classes required to do completion. This is a
>> new feature of the current release such that every time you switch
>> projects, the JDE scans the classpath for that project to build a list
of
>> classes to be used for completion and other purposes. This can take time
if
>> the classpath for a project has a lot of classes on it. The rescan occurs
>> only if you have used a feature that requires the class list, such as
>> method completion, in the current session. I'll add a customization
>> variable in the next release that will allow you to disable automatic
>> rescanning of the class list. If you do disable the autoscanning of the
>> classpath, this means that you will have to execute the rescan command
>> yourself everytime you change projects.
>>
>> Meanwhile, if it gets annoying, you can kill the scanning by killing the
>> beanshell. Of course, the next time the JDE needs the classlist, it will
>> restart the beanshell and rescan the classpath. Alternatively, you can
edit
>> or comment out out the form
>>
>> (jde-wiz-update-class-list)
>>
>> in the following code in jde.el
>>
>> (defun jde-reload-project-file ()
>> "If project context-switching is enabled (see
>> `jde-project-context-switching-enabled-p'), reloads the project file
>> for a newly activated Java buffer when the new buffer's project
>> differs from the old buffer's."
>> (interactive)
>> (if (and
>> jde-project-context-switching-enabled-p
>> (not (jde-debugger-running-p))
>> (not (string= jde-current-project jde-project-name)))
>> (progn
>> (setq jde-current-project jde-project-name)
>> (jde-load-project-file)
>> (jde-wiz-update-class-list))))
>>
>> - Paul
>>
>> - Paul
>>
>> >I have done a scan of the JDE customization and see nothing. I have not
>> >looked at the code to see what could be done.
>> >
>> >Thanks in advance.
>> >Erik Husby
>> >Domain Pharma Corp
>> >Suite 110 Vox: 781-778-3834
>> >10 Maguire Rd Fax: 781-778-3800
>> >Lexington, MA 02421 Email: [EMAIL PROTECTED]
>> >
>> >
>
>--
>________________________
>Jim Snyder
>Senior Software Engineer
>Copper Key Technologies
>402 High Point Dr., #201
>Cocoa, FL. 32926
>www.copperkey.com
>321.635.9070 x135
>
