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've got the following idea when planed to introduce some editor hints for C++ files, but don't want to introduce new ModuleInstall class in the module. - Some modules use ModuleInstall classes to do the following public @Override void restored () { EditorRegistry.addPropertyChangeListener(editorsTracker); } - intention is clear and now there is no other way to attach to EditorRegistry I have looked at white/black startup list and it seems we can reduce the number of loaded classes by the following approach + now need for some trivial ModuleInstall classes: - introduce EditorRegistryListener extends PropertyChangeListener - allow to register EditorRegistryListener in the lookup or some other declarative way => no class initialization during startup - EditorRegistry can lazily find them all when the first document is to be opened and attach registered listeners to itself
I guess most of the listeners care only about specific mime type so it would be good to specify it too: @EditorRegistryListener(mimeType={ "text/c", "text/cpp" }) class MyPCL implements PropertyChangeListener { ... }
With introduction of language embeddings in Parsing API I'm not sure whether explicit mime-type distinction is necessary.
I don't see why it is neccessary to hook up EditorRegistry listeners from ModuleInstall. Any code that needs to listen on EditorRegistry should add its listener when it is first needed/called/created/etc. I also don't see why this issue is blocking #177518 - CsmFileTaskFactoryManager does not even use EditorRegistry?! I'm not going to introduce an API contract without having good enough usecases justifying such a contract.