Bug 219669

Created attachment 125541 [details]
IDE log

There is an interceptor which suspends scan. It's used by the editor code completion, navigator, Go to type, etc. They suspend the scan when they are running.
Other actions can be added, the copy paste, cut paste sounds reasonable to me.

The parsing.api has an API to suspend & resume scan.
The platform (datasystem) needs to call it in copy, rename ops.
From discussion with Jarda the progress.api seems to be good candidate to give
user a chance to suspend the task.

Rather then doing some heuristics to find out what should and should not take precedence, we can implement additional suspend feature for certain progress tasks. Then the user can control which of multiple suspendable tasks should finish sooner. 

(probably we don't want the user to suspend anything, if there is a single suspendable task running, as we would like to finish tasks like background scanning one day)

Created attachment 126390 [details]
The suspend and cancel buttons on a progress in KDE4

Which features depending on the suspended task will not be functional until the user resumes the task and it finishes? Will this be indicated anyhow by the affected features?

(In reply to comment #6)
> Which features depending on the suspended task will not be functional until the
> user resumes the task and it finishes? Will this be indicated anyhow by the
> affected features?

among others the following essential functionality does not fully work until scanning has finished: code completion, navigation (go to type, go to declaration, etc), hints, find usages. Since 7.2 NB allows users to work with editor while scanning is still in process, however the related functionality is restricted or based on outdated (cached) info. E.g., when code completion is not yet available, it is indicated in the completion pop-up. Find usages with unfinished scan produces an incomplete (and often quite short) list of occurrences and a warning that it should be re-run after the scan has finished. Navigation just does not work; Ctrl-click on type name does nothing. Etc.

IMHO permitting to suspend a scan can lead to lots of confusion among general users. If permitted, it would certainly be a feature for power users only, as it would require strict attention and very good knowledge of why and when to apply it.

After offline discussion with Jarda here is a clarification of scenarios when the suspension mechanism would be used.

1) User is copying/cutting and pasting e.g. large amount of files which takes a long time to perform by itself. If the background scanning is in progress the copying is significantly slower.

Proposed solution: Show the copying in the Progress bar and enable suspend action for BOTH Background scanning and copying. With this functionality a user can decide e.g. that copying should be performed first so she suspends scanning, lets copying to be completed and then resume scanning manually.

2) This scenario is probably more obvious since the most of us (NB developers) encounter it very often. User wants to build some project externally (as we do in NetBeans) and she wants to suspend background scanning because it slows building significantly.

Since some of these details were not so obvious from the issue description I suggest to discuss it again on UI steering meeting taking this new information into account.

After UI team meeting and discussion with Jarda we've decided that this scenario is not a proper reason for introducing suspend functionality for Progress API, but the functionality itself can be useful for other scenarios. So I've reported new enhancement (issue #225012) in which we can discuss other relevant usages of it and I'm reassigning this particular issue back to Jarda.

Well, this is more a request for the parsing API. The parsing makes something else slow! Not the opposite way.

I have separate request to provide progress for copy/paste reported as enhancement 204570.

>Well, this is more a request for the parsing API. The parsing makes something
>else slow! Not the opposite way.
I've thought that the API | SPI should be defined by the lower layer.
However if you think that the PasteAction should depend on the Parsing API you can already suspend scan by:
Lookup.getDefault().lookup(ScanSuspendImplementation.class).suspend()

I'm troubled by the slowness of scanning with NetBeans 7.4 Beta. Is it correct that "Background scanning of projects" happens disturbingly every now and then even if "Enable auto-scanning of sources" has been disabled?  And even when I'm compiling a project, it seems that the scanning operation is competing with the compile operation.

I'm troubled by the slowness of scanning with NetBeans 7.4 Beta. Is it correct that "Background scanning of projects" happens disturbingly every now and then even if "Enable auto-scanning of sources" has been disabled?  And even when I'm compiling a project, it seems that the scanning operation is competing with the compile operation.

So I'm voting for faster performance and less cluttering automation.

>Is it correct that "Background scanning of projects" happens disturbingly every >now and then even if "Enable auto-scanning of sources" has been disabled? 
The Enable auto-scanning of sources just turns off the "Checking for modified files". It disables check of file modifications for which there is no fast native push change detection (inotify, FSEventChannel). Such a changes are detected using  file system crawling mostly when the IDE gets focus.

The background scan updates caches when there is a change in source root(s).
Without this metadata update the changed (added) files and their content (classes, methods, etc) will not be visible for the IDE (they will not be available in Go To Type, Go To File File, Find Usages, Go to Declaration, Code Completion, in case of Java Compile On Save even in Project Run).

Regarding the concurrent run of paste and scan I agree that these actions should not run in parallel. There are several such actions like navigation, refactoring, code completion which already suspend the scan. The only thing needed is that the paste action suspends the scan until the paste is done.

Created attachment 143358 [details]
Initial sketch of resumable handle

Resetting to default module owner. I still believe "suspend" of various background tasks is the only solution to the problem, but I am not going to push it forward myself.