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

[Vlad Dumitrescu <vladdu55@xxxxxxxxx>]

Hi!

On Tue, Jan 17, 2017 at 7:13 PM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

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.

Ok, will do. 

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.

I understand. After sending the question I realised that this public API would be needed only while people migrate their code, which would be stupid. We can live with the access restriction warnings :-)

 

> 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.

This is absolutely the best way to go. The only disadvantages are that it might take a while to see the implementation published and that it may be difficult to backport to previous Eclipse versions. And usually there is pressure to deliver the stuff yesterday :-)

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.

Good idea. It's going to be a lot of work to straighten things up, the original editor was written for 3.4, I think, and there's cruft that might not be needed anymore, but how to know that? *sigh*

Thanks!

best regards,

Vlad