Re: [platform-dev] Generic Text Editor for pure E4

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi,

All I can throw into this discussion is
https://github.com/BestSolution-at/code-swt - It was a PoC which i did
not worked on afterwards.

In the end all main building blocks for editors are in
eclipse.text/jface.text who does not depend on any compat-layer APIs.

Tom

On 04.07.19 10:04, Mickael Istria wrote:
> Hi,
> 
> See below a few question, and then some ideas.
> 
>> the core of the Generic Text Editor is not dependent on E3.
> 
> Can you please elaborate what you specifically mean by this? I'm not a
> e4 user myself (not really interested in it for my IDE-related work
> since e3 just does the job quite well), so I'm genuinly curious about
> what specific criteria are to check to claim something is dependent on
> e3 or not.
> Are there already stories of the Platform TextEditor working on plain E4
> without E3? As long as it's not there, then we cannot really imagine
> moving downstream to the Generic Editor.
> Also, what is the issue shipping pieces of e3 in an e4 app?
> 
>> trying to remove E3 dependencies from the Generic Text Editor.
>> [...]
>> I browsed the code of the "ExtensionBasedTextEditor"
> 
> I confirm this is probably quite hard, I guess the type hierarchy of the
> editor itself (and it means a lot as parent are providing a lot of the
> value) is full of e3 APIs. But maybe I'm wrong on the type stack for the
> Generic Editor is already ready.
>  
> 
>     but we can gain a lot from this.
> 
> 
> Can you please give example of use-case that E4 enables easily that are
> impossible or very hard to implement with e3 APIs?
> 
>> The Generic Text Editor may be a good starting point: it has a lot of
> services to interact with and it will be natural to utilize OSGi
> services and E4 approach.
> 
> If you want to add support for OSGi Services additionally to extension
> point in the current Generic Editor, that would be welcome, since it
> wouldn't reduce the feature set nor break backward compatibility.
> About using the e4 approach, then it seems to me you mean "ability to
> load extensions with e4 annotations". It also seems like something that
> can be done, if it's not already there.
> 
> Can a pure E4 generic editor be backward-compatible with the current one
> (read extensions and process them similarly, and have the same feature
> set)? If yes, then I would recommend migrating the porting Generic
> Editor rather than creating a new one. If we have both, then it's twice
> more maintenance cost, the IDE will keep the legacy one that just works
> for it and both editors will ultimately diverge, and given the
> priorities of the community regarding text edition (mostly the IDE),
> there will be new features in the current Generic Editor that won't be
> implemented in the pure-e4 one and the pure-e4 one will get obsolete and
> will conclude as an expensive unsuccessful experiment.
> For this reason, I'm personally -1 to have Platform hosting a new editor
> for this, however, I'm +1 in making the Generic Editor as much
> e4-friendly as possible (as long as it doesn't have any negative impact).
> 
> Cheers,
> 
> 
> _______________________________________________
> platform-dev mailing list
> platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck