Re: [platform-text-dev] Generic editor API usage

[Mickael Istria <mistria@xxxxxxxxxx>]

Hi Vlad,

> I would like to start using the generic editor, but at the moment it doesn't have all the features of my existing editor.
> [...]
> Also, the configuration can't be used but with an editor, but it is useful to use it on Viewers (for example, the syntax highlight preview).
> Should I open tickets for these issues, or is discussing them first preferable?

Can you please create feature requests for each of the ones you find missing?
I think tickets are always more efficient as they allow tracking, planning, and scale better with time - old mailing-list discussions never resurrect, bugtracker tickets often do. The only missing stuff to make tracker fully better than a mail are threaded discussions.

> I can inherit from ExtensionBasedTextEditor instead of TextEditor and I think I can do a smooth transition whenever new features are available. I can imagine that this would be the easiest way for a transition for many other users. But the genericeditor plugin doesn't export its packages, so my question is: should I live with restricted access warnings, or would you consider exporting the packages?
> [...]
> Following from my previous message, it's not working to just ignore the restricted access warning, because the ExtensionBasedTextViewerConfiguration is final and it would need to get extended in order to add more features to the editor.

Inheritance is often an anti-pattern. It's the pattern that has driven Eclipse developers to implement a plethora of pretty similar editor classes for code edition, and it is the pattern we want to avoid there. If we let the class be accessible and extensible, then we simply don't change a thing compared to the current - we'd just have moved the issue to a new class. Moreover, maintaining a new set of APIs is something we don't want to add to the duties of the Platform team. So overall, there is no future for expecting those classes to be APIs.

> If the vision for the generic editor is to handle *all* possible customizations, then it makes sense to keep the classes private, but it's going to be a long way there.

Yes, it is somehow the vision. This is an infinite task for sure, and things get added by priority/availabilityof the contributors. It's indeed a long way to go, but the more people contribute and the faster we go. Not having APIs and forcing interested people to contribute rather than to extend is a way to enforce sharing the work (as opposed to the inheritance model where adopters all implement the same thing in their own classes and never contribute back).
The only way to add features to the Generic Editor is to contribute to it.

But as I read your mails, it seems like you're fully ready to start contributing by opening bugs ;)

That said, let's talk about pragmatic dirtiness ;) Rather than trying to extend the class, you might be able to consume the extensions directly, just reading the registry and re-implementing the approach taken by the ExtensionBasedTextEditor. It's not elegant, but it might unlock you from time to time.

Cheers,

--
Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets