Summary: | Provide IReconcilingStrategyExtension2 to handle IReconciler#install/uninstall | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Angelo ZERR <azerr> |
Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | daniel_megert |
Version: | 4.7 | Keywords: | api |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Angelo ZERR
2017-08-23 15:55:22 EDT
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.
|