Opening a file of a language for the first time is a lot slower in nightly compared to stable. An easy way to reproduce this is to create a new Spoofax project in stable and nightly and compare the time it takes to open all the editors.

It seems like this was introduced after the outline changes, but I am not certain. Maybe it is lazily loading a lot of stuff?

Submitted by Gabriël Konat on 26 July 2013 at 02:03

I noticed this too and will investigate if it has to do with the outline.

This problem is indeed caused by the new outline, but for a good reason.
For backwards compatibility purposes, we decide whether to initialize an IMPOutlinePage or a SpoofaxOutlinePage during editor initialization. To make this decision, I ask the interpreter if an outline strategy is defined and this requires initialization of things that would otherwise only be initialized after editor initialization.

Maybe we should stop supporting esv-based outlines and simply initialize a SpoofaxOutlinePage. Then we can also clean-up some code.
A first step would be to remove stuff from org.strategoxt.imp.runtime and org.strategoxt.imp.generator . Outlines for existing editors will then suddenly disappear, but nothing would really break in the sense that you can still build your project and use your editor.
A second step would be to remove outline stuff from the esv syntax, which would break existing projects. So then we need to remove esv-based outline definitions from all Spoofax editors first.

Anyone against this?

This is only fine, if you provide an easy to follow migration strategy. This would include

1. A generic outline strategy which uses the same heuristics as the old outline (where the heuristics where encoded in Java, but collect-one might do the job in Stratego).
2. A way to customise the generic strategy similar to old esv outline rules.
3. A text for the next release, which explains how to migrate esv outline rules to customisation rules.
4. A builder for esv files which generates the customisation rules automatically (optional, not sure how hard this is).
5. Working outline views for all meta languages (SDF, NaBL, Stratego, ESV).

Is it possible to defer the initialization and/or do it in the background somehow?

@Guido: ok, then I propose that the generated heuristic-based outline definition looks like this:

module Entity-Outliner.generated

imports
  include/Entity
  lib/outline-library.generated

rules
  outline-strategy = simple-label-outline(to-outline-label)

  to-outline-label: Module(name, _) -> name
  to-outline-label: Entity(name, _) -> name

In this way we show the user where the labels come from. IMHO this is better than hiding this information because I think it is something that will be customized by users frequently.
We can possibly improve the heuristics that determine which symbol provides a name for a construct, by using SDF labels and NaBL name def sites if available.

@Gabriel: Not really I’m afraid. I could try to make a call from the Spoofax outline into the IMP outline such that we can always initialize a Spoofax outline, but I would rather spend my time on kicking out the IMP outline. BTW if it really bothers you, you can defer initialization manually by closing the outline view before opening the editor ;-)

NaBL used to generate rules for nabl-name mapping named elements to their names. This seems not to be available in master, but I can bring it back. However, legacy projects might not have NaBL definitions. I agree that making the label explicit is very useful, but it might be harder because you need to apply the heuristics now on the signature level, not on the AST level. But having analyses on the signature level is a useful exercise anyway. Thus, if you like the idea, go for it.

This has been fixed in nightly.