This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have some problems with cancelling some longer-term taks after source modification. For example user makes a change in css editor, after some time the parsing starts. But if the user continues typing meanwhile, the task is not cancelled, it finishes and starts the parser again. This is IMHO unacceptable. I belive we need to somehow make at least virtual source generation, parsing cancellable. Similar way like the SemanticAnalyzer does.
It sounds like you want to be able to cancel -parsing-. That's difficult. There is support in GSF (and Retouche) for canceling the various source tasks that run -after- parsing: code folding, semantic highlighting, quickfixes, navigator, etc. (This wasn't working for all these tasks; I found a bug which I've now fixed). However, canceling the parse task itself isn't easy. It looks like this scenario is deliberately prevented: From Source (and same in JavaSource): static Phase moveToPhase (final Phase phase, final CompilationInfoImpl currentInfo, final boolean cancellable) throws IOException { The last parameter is cancellable - which is passed in as false for the scenarios I tested with. It looks like a lot of the infrastructure in JavaSource/Source is tied to this. Inside the moveToPhase code there is this: if (cancellable && currentRequest.isCanceled()) { return Phase.MODIFIED; } I tried adding if (currentRequest.isCanceled()) { return Phase.MODIFIED; } in several places in the method (before and after computing the embedded source translation, as well as after each parse for each mimetype). However, that seemed to break a lot of things - code completion etc. no longer works. I'll play with this a bit more to see if it will help. (To exercise this I added a Thread.sleep(50000); in my embedding model translator). But I'm a bit afraid to mess with this part of the code... I will definitely push my other cancellation fixes though which should make quickfix cancellation for example start working.
Since this does not appear to be needed for fixing issue 129561, is this still a P2? Should we change it to ENHANCEMENT?
I think profiler data for 129561 showed that the bottlenecks were elsewhere (most likely in the highlighting area; GSF might need to change the highlighting API to accommodate large buffers where computing the highlighting bags is cheaper. On the other hand, Mila just improved caching in the editor so this is less serious now. In any case, I agree that we should change this to enhancement. Most GSF source tasks -are- cancelable now - just not parsing for the reasons I outlined in my previous post. Improving this would definitely be a good idea.
>It sounds like you want to be able to cancel -parsing-. That's difficult. I probably not expressed my thoughts clearly, my concern was not just about the parser but about other tasks triggered once the parsing finishes. At least StructureScanner should be a CancellableTask like SemanticAnalyzer is. Virtual source generation can also take some time and resources so having it cancellable would be better. Some other things like navigator UI update is the same case - once it starts it will finish even if the source has been modified meanwhile.