editor-init suggests that it inits the editor and should be called before static analysis. You also have to call it if you need to re-analyse, e.g. to work around #262. But it’s generic implementation makes the abstraction leaky. You have to be aware that it deletes all dynamic rules. For example, this causes problems with the testing language, when testing builders that call editor-init.

Seems like we need more specific initialisation strategies. Who likes to work with dynamic rules, should delete just these rules, not all rules.

Submitted by Guido Wachsmuth on 29 December 2011 at 12:08

The reason editor-init works the way it does now is that it has allowed Spoofax plugins to leave dynamic rules in scope when the analysis finishes. As long as the rules are in scope, editor services like reference resolving can make use of them. Then, after a new analysis is started, they are cleared again. Deleting rules manually tends to be error-prone, and the current model seemed to work well except in those case where users for whatever reason deleted the call to editor-init… FWIW, we’re rethinking dynamic rules, and we’re hoping to avoid an editor-init like strategy in the future.