Community
Participate
Working Groups
All IReconcilingStrategy that I have developed and I have seen needs to work with ITextViewer (IDocument is not enough). Here some sample like JavaCompositeReconcilingStrategy, SpellingReconcileStrategy, XMLFoldingStrategy (from WTP), etc. This viewer is setted in the constructor or with a setter. IMHO I think Platform should provide a new interface IReconcilingStrategyExtension2 like this: ---------------------------------------------------------- package org.eclipse.jface.text.reconciler; public interface IReconcilingStrategyExtension2 { void install(ITextViewer textViewer); void uninstall(); } ---------------------------------------------------------- MonoReconciler should call the 2 methods of this API. This new interface will give 2 capabilities: * get the ITextViewer in the strategy with a standard mean. * detect when reconciler is unistalled and implement some dispose code if needed. I think this new API should be welcome with Generic Editor and multiple reconciler strategy described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=520686
Some strategies even need the editor, so, it would split the installation. Having an uninstall was not needed so far. We can take a closer look if there is a real need from a new strategy.
> Some strategies even need the editor, so, it would split the installation. I have not found those kinds of strategies? Have you a sample? > Having an uninstall was not needed so far. We can take a closer look if there is a real need from a new strategy. I have a sample with my PR for lsp4e https://git.eclipse.org/r/#/c/103579/3/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/highlight/HighlightReconcilingStrategy.java This HighlightReconcilingStrategy adds caret listener on install and removes caret listener on uninstall of reconciler. If MonoReconciler could takes care of this lifecycle of install/uninstall, I could remove the custom reconciler https://git.eclipse.org/r/#/c/103579/3/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/highlight/HighlightReconciler.java
(In reply to Angelo ZERR from comment #2) > > Some strategies even need the editor, so, it would split the installation. > > I have not found those kinds of strategies? Have you a sample? You listed it in comment 0: JavaCompositeReconcilingStrategy > > Having an uninstall was not needed so far. We can take a closer look if there is a real need from a new strategy. > > I have a sample with my PR for lsp4e > https://git.eclipse.org/r/#/c/103579/3/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/highlight/HighlightReconcilingStrategy.java I'd prefer to have a usage of the new API inside the SDK. Maybe the Generic editor could start with it.
> You listed it in comment 0: JavaCompositeReconcilingStrategy Yes you are right, sorry. In this case constructor is a good idea. > I'd prefer to have a usage of the new API inside the SDK. Maybe the Generic editor could start with it. org.eclipse.ui.texteditor.spelling.SpellingReconcileStrategy could use it, to avoid to set the sourceViewer in the constructor, no?
(In reply to Angelo ZERR from comment #4) > > You listed it in comment 0: JavaCompositeReconcilingStrategy > > Yes you are right, sorry. In this case constructor is a good idea. > > > I'd prefer to have a usage of the new API inside the SDK. Maybe the Generic editor could start with it. > > org.eclipse.ui.texteditor.spelling.SpellingReconcileStrategy could use it, > to avoid to set the sourceViewer in the constructor, no? Not really. In addition to the viewer it needs the spelling service. For me it makes no sense to set the spelling service in the constructor and then pass the viewer via #install.
> Not really. In addition to the viewer it needs the spelling service. For me it makes no sense to set the spelling service in the constructor and then pass the viewer via #install. Ok Dani thanks for your feedback! I hope generic editor will provide this kind of interface to implement clean IReconcilingStrategy.
