Replace "Default" text editor with "Generic" text editor about eclipse.platform.ui

[vogella]

+1 for only one text editor in the IDE. This will reduce the confusion for end users with the Eclipse IDE

Nice to see suggestions for simplifying the UX in the IDE from you Andrey.

[mickaelistria]

I'm a bit worried about overriding the ids of editors. I imagine some RCP products would like to use the DefaultEditor (plain text) to edit plain text, without highlighting nor anything. I suspect the ids to be considered as stable as API, so "org.eclipse.ui.DefaultTextEditor".equals(getEditor().getId()) && !(getEditor() instanceof ExtensionBasedTextEditor) should remain true to ensure we don't break people treating id as API.
What I think would be more interesting would be to relabel the editors (as it is being discussed in #1385 ) and just make that the default behavior of IDE.open(...) methods and the default return value for editor associations uses the Generic Editor, or whichever other editor with something based on a preference. Then we can flip the default editor in the IDE by changing the default preference, and consumers who want to stick to another editor can override the preference.
This can also serve past or future stories where some better-than-default editor was existing (eg LicClipse) and it was impossible to really make it default.

So I would suggest we reorganize this proposal as "Define and use a preference to choose what is the default editor"

[iloveeclipse]

What I think would be more interesting would be to relabel the editors (as it is being discussed in #1385 )

Please not yet another discussion how to rename two text editors! It doesn't matter how we name these two editors, someone will be always upset by the chosen name. Better to fix the root cause and have one "Text" editor.

and just make that the default behavior of IDE.open(...) methods and the default return value for editor associations uses the Generic Editor, or whichever other editor with something based on a preference.

As described in the proposal, currently IDE doesn't allow to choose "preferred" editor if there are few editors registered for same content type. That must be implemented in your proposal, but the problem with two "text editors" appearing in UI will still remain and confuse everyone.

I'm a bit worried about overriding the ids of editors.

That's IMO the main issue here, the idea is to be able to switch "overriding" off for a RCP product that don't want to have it. I believe that is possible.

I also believe this will be a very small amount of products that won't have the new feature, and most of downstream clients would be happy to get rid of "schizophrenia" we have with two text editors.

[mickaelistria]

So maybe we can extract the extension point that define the Default editor in a separate bundle, and not including anymore in Platform?
As a preliminary work, we can also try to set the the default attribute of the Generic Editor definition in plugin.xml to true and see what happens from there.

[iloveeclipse]

So maybe we can extract the extension point that define the Default editor in a separate bundle, and not including anymore in Platform?

We can't move extension point that defines any editor in question here to other bundle as this will again break compatibility with existing products that would need to change their code/imports.

As a preliminary work, we can also try to set the the default attribute of the Generic Editor definition in plugin.xml to true and see what happens from there.

Once again, that will not fix content types association problem and will not "hide" the twin contributions in UI.

[mickaelistria]

existing products that would need to change their code/imports.

Existing products would "only" have to add the legacyTextEditor fragment if they want it in their RCP; but by default it would be removed. In general, anything that changes the "default" behavior can break some clients, and every such change should ideally come with instructions of how to revert to legacy behavior (whether it is about adding a fragment, setting of preference, or whatever switch... is equivalent).
If you want that products keep the legacy editor by default, then it means we need 1 more switches in Platform products to enable "hiding" the DefaultEditor (I suspect we can remove an entry from the editor registry based on some flag).
But let's also discuss what people expect from a Platform: they expect the platform to also provide some innovations/fixes that they don't provide themselves. If Platform has established that the Generic Editor is best and that the Text Editor is worth being retired, then Platform has the responsibility of pushing this improvement to downstream consumers too. So changing the default by retiring the legacy text editor is IMO best here, as long as we provide a simple path to people who want it back (and with my proposal above, the migration path is just about adding a fragment).

Note that in the end, I don't really care about the legacy Text Editor personally; I just shared some potential concerns with overriding the id being more error-prone than retiring the editor; but in the end, I won't veto anything that is about making the Generic Editor the default one in the SDK. To be honest, that was one of our long-term goals with @sopotc when we introduced it. Having other community members actively requesting it and likely to make it happen is too good, and I'd enjoy seeing it happen even if it might hurt some products; because I think it's still in the best interest in the Platform itself.