Community
Participate
Working Groups
Generic Editor provides an extension point to register "reconciler". If you wish to register several IReconcilerStrategy (ex: folding, spelling, validation, codelens, etc), you must create a reconciler class per IReconcilerStrategy IMHO I think genericeditor should improve reconciler extension point to register a list of IReconcilerStrategy for a given reconciler (one reconciler for a list of IReconcilerStrategy) to avoid having just one Thread to execute list of IReconcilerStrategy (spelling, folding, etc) and not have one thread (one reconciler per IReconcilerStrategy). Here a quick idea: ------------------------------------ <extension point="org.eclipse.ui.genericeditor.reconcilers"> <reconciler id="SingleReconciler" class="org.eclipse.ui.internal.genericeditor.SingleReconciler" contentType="org.eclipse.core.runtime.text"> </reconciler> <reconcilerSrategy renconcilerId="SingleReconciler" class="FoldingStrategy" </reconcilerSrategy> <reconcilerSrategy renconcilerId="SingleReconciler" class="SpellingStrategy" </reconcilerSrategy> </extension> ------------------------------------
Reducing priority as the current extension point and usage for reconcilers doesn't seem to cause any issue or blocking any use-case at the moment.
To my understanding, the Generic Editor, as with all SourceViewers, can only instantiates one reconciler. For the Generic Editor, if multiple are registered, the most specialized one is applied. To apply multiple strategies, they must be compiled into one strategy and attached to one reconciler (as reconcilers can only have one strategy). This suggestion does bring up a point that possibly reconcilers (along with presentation reconcilers, content assistants and other parts) should be lists instead of just individual elements allowing for multiple to be assigned to an editor instance at once, however I think that would be out of the scope of this bug.
> Reducing priority neas the current extension point and usage for reconcilers doesn't seem to cause any issue or blocking any use-case at the moment. Since I have done a PR to register a default indent folding which is regsitered with reconciler, I cannot benefit with the 2 reconcilers "higlight symbol" and "folding", only folding is working. > To my understanding, the Generic Editor, as with all SourceViewers, can only instantiates one reconciler. For the Generic Editor, if multiple are registered, the most specialized one is applied. Exactly, it's the problem that I have. > To apply multiple strategies, they must be compiled into one strategy and attached to one reconciler (as reconcilers can only have one strategy). Yes exactly, JDT supports that with their org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy. We could use it. IMHO, I think this bug is important to support "folding" and "highlight symbol" both.
Here a new idea to support spelling, folding, higlighting symbols (mark occurrences) both. The idea is to provide an extension point to register reconciler strategy instead of registering reconciler. At first generic editor could defines a default folding indent strategy liek this: ------------------------------ <extension point="org.eclipse.ui.genericeditor.reconcilers"> <reconcilerSrategy type="folding" class="org.eclipse.ui.internal.genericeditor.folding.IndentFoldingStrategy" contentType="org.eclipse.core.runtime.text" </reconcilerSrategy> </extension> ------------------------------ So by default folding is done by using indentation. To disable this folding strategy we could provide a preferences. You can note the type attribute which defines that this reconciler strategy is for "folding", so you could override this folding strategy by custom stratgy like this: ------------------------------ <extension point="org.eclipse.ui.genericeditor.reconcilers"> <reconcilerSrategy type="folding" class="...MyCustomFoldingStrategy" contentType="my.content.type" </reconcilerSrategy> </extension> ------------------------------ Generic Editor manage reconcilerSrategy by providing a default reconciler DefaultReconciler which extends MonoReconciler and waits for a list of IReconcilerStragty like JDT https://github.com/eclipse/eclipse.jdt.ui/blob/master/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/text/JavaReconciler.java which uses JavaCompositeReconcilingStrategy which extends https://github.com/eclipse/eclipse.jdt.ui/blob/master/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/text/CompositeReconcilingStrategy.java Generic Editor could copy/paste this CompositeReconcilingStrategy class. So after we will able to define other reconcilerSrategy. lsp4e could defines ------------------------------ <extension point="org.eclipse.ui.genericeditor.reconcilers"> <reconcilerSrategy type="higlighting" class="org.eclipse.lsp4e.operations.highlight.HighlightReconcilerStrategy" contentType="org.eclipse.core.runtime.text" </reconcilerSrategy> </extension> ------------------------------ instead of defining: ------------------------------ <extension point="org.eclipse.ui.genericeditor.reconcilers"> <reconciler class="org.eclipse.lsp4e.operations.highlight.HighlightReconciler" contentType="org.eclipse.core.runtime.text"> </reconciler> </extension> ------------------------------ In other words HighlightReconciler which is a reconciler should be replaced with a new class HighlightReconcilerStrategy which implements IReconcilerStrategy. With this solution we could have "folding" and "higligthing" both for lsp4e. Hope you will like this idea.
A new use case is to display color inside editor for CSS editor. See https://github.com/mickaelistria/eclipse-bluesky/issues/30
In other words, I would like to support for CSS language the following features both: * folding * highlight symbols * CSS coloration Each features should be implemented with IReconcilingStrategy (I have started with higlight https://git.eclipse.org/r/#/c/103579/3/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/highlight/HighlightReconcilingStrategy.java) IMHO to have a clean code, thoses strategies should implement the IReconcilingStrategyExtension2 that I have suggsted in https://bugs.eclipse.org/bugs/show_bug.cgi?id=521326
(In reply to Lucas Bullen from comment #2) > To my understanding, the Generic Editor, as with all SourceViewers, can only > instantiates one reconciler. Right, but we could have a "composite" reconciler that delegates to multiple reconcilers. Any 1-1 mapping can hopefully turn into a 1-N mapping thanks to composition and delegation > To apply multiple > strategies, they must be compiled into one strategy and attached to one > reconciler (as reconcilers can only have one strategy). I think we need a composite reconciler that invoke install/uninstall of multiple children reconciler, and which return a composite strategies. > This suggestion does bring up a point that possibly reconcilers (along with > presentation reconcilers, content assistants and other parts) should be > lists instead of just individual elements allowing for multiple to be > assigned to an editor instance at once, however I think that would be out of > the scope of this bug. Several extensions of generic editor allow that with such composition pattern already. But you're right, it's out of the scope of this bug. > I cannot benefit with the 2 reconcilers "higlight symbol" and "folding", only folding is working. This does simply mean we need to be able to attach multiple reconcilers to the Generic Editor. No new extension point is need for that. We just have to use a composition of the various contributed reconcilers. To be honest. I disagree it's a good thing to define such complex composition in plugin.xml and to let plugin.xml define a reconciler in such a declarative way (hooking the strategy inside a declared reconciler). I don't get the benefit compared to doing it in regular Java code, and as Java is more powerful than plugin.xml, it would allow richer composition. I also would like to stay away from declaring "families" or "types" of reconcilers from this extension point as much as possible. I would love to see some finer grained extensions (one for folding, one for spelling and so on), but it's really not the way current Eclipse code is working, and I don't want to emulate that in Generic Editor. If we want something cleaner, then we first need to propose new interfaces and APIs to JFace for those specific stories (folding, highlight...). Then, once we have those "business" APIs in place, we can consider new extension points for those. But the place where to fix/add it is JFace, not generic editor; let's not hit the wrong layer as it costs a lot of issues afterwards.
> But the place where to fix/add it is JFace, not generic editor; let's not hit the wrong layer as it costs a lot of issues afterwards. My fear is that it will take a long time to define and accept those kind of API in JFace. IReconcilingStrategy (and IReconcilingStrategyExtension2) are enough to support folding, highlight, etc. For me, the main problem is to define a type for strategy (folding, highlight), but this requirement is for only Generic Editor, is JFace will benefit of those kind of interfaces which types IReconcilingStrategy?
(In reply to Angelo ZERR from comment #8) > My fear is that it will take a long time to define and accept those kind of > API in JFace. I don't think that's entirely true. For sure, introducing a new API in JFace will require very detailed review and so on. But it actually leads to better results that don't need to change afterwards. So on the long run, taking the time to design good APIs with the necessary review cycles saves a lot of effort on the lifecycle of the Platform developmet. > IReconcilingStrategy (and IReconcilingStrategyExtension2) are > enough to support folding, highlight, etc. Sure, but look at the current state, it's a mess: reconcilers can do anything, and the reconcilers have to deal with a lot of low-level boilerplate (listeners and so on), they do not offer a way to identify their roles. FoldingStrategy should be an interface that takes as input the FoldingAnnotationModel. Highlight doesn't need to react to document change (only selection change), so a ReconcilingStrategy is overkill for it and so on. If we want good APIs, we need them to map use-cases, not to be so generic that they can do anything. > For me, the main problem is to define a type for strategy (folding, > highlight), but this requirement is for only Generic Editor, is JFace will > benefit of those kind of interfaces which types IReconcilingStrategy? Ok. Let's keep the grain fine enough to not mix too many concerns at once and stay focused on the individual changes and the value they can provide. Please open another bug to consider families in reconciler extension of the generic editor.
Mickael, is there smth still pending here/
(In reply to Alexander Kurtakov from comment #10) > Mickael, is there smth still pending here/ Not really something that we've strongly needed so far. Should I mark it as WONTFIX?
