(This is a summary of the discussion in #spoofax on IRC yesterday, so it doesn’t get lost.)

Problems with current architecture

• There is no way for other services to wait for the analysed ast. So all editors call analysis again: wasting computation by duplicate calculations
• Analysis Jobs get queued: resulting in a long list of “Analysing updates to …”, wasting computation by calculating analysis for outdated ASTs
• This results in outdated editor errors

Design for new architecture

Editor services

Some services might base their first view on the source AST, and then update when the analysed AST is available, but most will base on the last analysed AST, and update when a new one comes in I think yes.

They should be reactive to when a new AST comes in, internally schedule a job in the background, then update the UI.

Analysis Jobs

The calculation of the new AST should be cancellable instead of queued like it is now.

Submitted by Daco Harkes on 28 March 2014 at 10:22

If not done before, I will refactor this during my Oracle internship (June-August)

Regarding editor services:
We indeed need a way to react on analyzed AST updates, at least for the outline view and graphical views/editors and possibly for other views/services in the future. I believe Gabriel already implemented something for this but I haven’t been able to try it out yet.
I think for the properties view things are almost working properly now. It shows the properties of the latest analyzed AST and waits in the background to update the properties view if the selection changes while analysis is busy. However, if you change the selection multiple times while analysis is busy, it will recalculate the properties view multiple times (for each selection) after analysis is finished. Instead, it should only recalculate it for the latest selection by cancelling all previously scheduled properties view jobs.

Regarding job cancelling:
We may want to approach this in a similar way as Eclipse does for the outline view. Outline jobs that are currently running are not interrupted, but if a new job is scheduled, all previously scheduled jobs are cancelled. In this way you will still get updates while typing and you don’t have to wait long for the latest update to become visible once you stop typing. This approach would also work for the properties view.

related issue: getCurrentAnalyzedAst returns null if you don’t save or close and reopen an editor after rebuilding a project. Currently, this results in an empty properties view after rebuilding. I’ll fix this for now by calling getAnalyzedAst (i.e. triggering an additional analysis) in case getCurrentanalyzedAst returns null, but some proper refactoring would be really necessary.