Community
Participate
Working Groups
A lot of project like JSDT, JDT, typescript.java, etc defines an Outline & Quick Outline with same code (AbstractInformationControl, etc) that they define in their project. It should be better to have a common project which defines thoses classes. It should be cool too if Generic Editor could provide an Outline & Quick Outlien support with extension point to : * define tree label provider * define tree content provider * define the model to use to fill the tree. Please note that to avoid freezing teh UI, the model should be getted with async mean. I have done that inside typescript.java with listener model. See https://github.com/eclipselabs/eclipse-language-service/issues/56#issuecomment-257086656 where this discussion has started.
IMHO, the Generic Editor should define a CNF-based outline as default. then contributing to outline would be plain usage of Common Navigator Framework.
Actually, anyone can already contribute an outline to the generic editor. Simply add an extension such as: <extension point="org.eclipse.core.runtime.adapters"> <factory adaptableType="org.eclipse.ui.internal.genericeditor.ExtensionBasedTextEditor" class="org.eclipse.languageserver.outline.EditorToOutlineAdapterFactory"> <adapter type="org.eclipse.ui.views.contentoutline.IContentOutlinePage"> </adapter> </factory> </extension> with a smart enough factory to only return an outline when it makes sense to you according to the content of the editor. I don't think it makes sense for the generic editor to enforce a specific type of Outline. It's better to have it only focusing on text and leave the door open to whatever outline makes sense.
(In reply to Mickael Istria from comment #2) > Actually, anyone can already contribute an outline to the generic editor. > Simply add an extension such as: > > > <extension > point="org.eclipse.core.runtime.adapters"> > <factory > > adaptableType="org.eclipse.ui.internal.genericeditor. > ExtensionBasedTextEditor" > > class="org.eclipse.languageserver.outline.EditorToOutlineAdapterFactory"> > <adapter > > type="org.eclipse.ui.views.contentoutline.IContentOutlinePage"> > </adapter> > </factory> > </extension> > > with a smart enough factory to only return an outline when it makes sense to > you according to the content of the editor. > I don't think it makes sense for the generic editor to enforce a specific > type of Outline. It's better to have it only focusing on text and leave the > door open to whatever outline makes sense. Mickael, there are 2 issues I can see with this: 1. reference to internal class for adaptableType - we should never recommend such approach in new development 2. how would one implement such smart factory that would work only for generic editor and not for others - some example/documentation would be needed at least.
Reopen to clarify the two issues from previous comment here.
(In reply to Alexander Kurtakov from comment #3) > Mickael, there are 2 issues I can see with this: > 1. reference to internal class for adaptableType - we should never recommend > such approach in new development > 2. how would one implement such smart factory that would work only for > generic editor and not for others - some example/documentation would be > needed at least. I think this extension would allow to use the AbstractTextEditor as adaptableType so it would work with any text editor. This needs to be verified though.
Correct my if I'm mistaken, but wouldn't the adapter be used for all ExtensionBasedTextEditor based editors in that case. My understanding was that AdapterManager only allows registering a single adapter factory for a given adaptableType, adapter tuple. It would be helpful to have an extension that allows specifying the IContentOutlinePage to use for a given content type. Such a system would be particularly useful for editors that use the LSP4E to allow specializing the outline page for a particular language server.
(In reply to Philip Alldredge from comment #6) > Correct my if I'm mistaken, but wouldn't the adapter be used for all > ExtensionBasedTextEditor based editors in that case. My understanding was > that AdapterManager only allows registering a single adapter factory for a > given adaptableType, adapter tuple. Mmmm, looking at the code and javadoc, yeah you're right, that's annoying... If need be, we can add and use a specific IAdapterManager in the genericeditor bundle supporting multiple factories, and trying all available ones for the requested adapter source/target until one returns a non-null value. Then, we'll be able to consider moving it to org.eclipse.core.runtime. > It would be helpful to have an extension that allows specifying the > IContentOutlinePage to use for a given content type. Such a system would be > particularly useful for editors that use the LSP4E to allow specializing the > outline page for a particular language server. +1!
An useful use case: 1. open a .target file with the generic editor, 2. display the target outline
> It would be helpful to have an extension that allows specifying the > IContentOutlinePage to use for a given content type. Such a system would be > particularly useful for editors that use the LSP4E to allow specializing the > outline page for a particular language server. LSP4E's outline page is based on Common Navigator Framework, which is already very customizable. Can you please elaborate what kind of customization you'd need here that would not be possible with common navigator framework? This answer above doesn't fix all issues related to Generic Editor and Outline, but the exact use-case seems necessary to identify whether relying on CNF is a good thing or not.
