Re: [lsp4e-dev] Targetting Photon on master?

[Mickael Istria <mistria@xxxxxxxxxx>]

On Wed, Dec 20, 2017 at 5:59 PM, Elliotte Rusty Harold <elharo@xxxxxxxxxxx> wrote:

I'd be reluctant to abandon 4.7 this early. I still get email from
users complaining about a 4.5 minimum for my plugin.

It's not really abandoning from the project perspective, it's more switching main target, but whoever wants to still support 4.7 could still do it on a 0.5.x branch inside project and LSP4E could still have releases targeting 4.7.

What, specifically, is gained by requiring 4.8? Can we see a detailed
list of how this helps? What bugs are fixed in 4.8 that impact LSP4E?
What new APIs do you want to rely on?

* Common highlight support: https://www.eclipse.org/eclipse/news/4.8/M4/#generic-editor-highlighter

* CodeMining: https://www.eclipse.org/eclipse/news/4.8/M5/#codemining-extension-point

* Aggregate hovers: https://www.eclipse.org/eclipse/news/4.8/M2/#generic-editor-aggregates-hover

* Multiple reconciliers: https://bugs.eclipse.org/bugs/show_bug.cgi?id=521418

* Auto-Edit strategies: https://www.eclipse.org/eclipse/news/4.8/M1/#generic-editor-autoeditstrategies

are the current new features I have in mind. Note that some features in LSP4E do already rely on those and would simply not be "detected" is using LSP4E in pre-4.8, but wouldn't fail LSP4E.

And here are a few links to bugfixes that LSP4E could build upon to improve some of its code:

* http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=a07fab236bceb22de2fc243a1a47d5987d9a533d

* http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=13f734bdd7951d8b59cfd73ae8cbc2793f76bf0f

* http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=9eebfa376eeadd862a2ecd0ad941ef1a4dbda834

* https://bugs.eclipse.org/bugs/show_bug.cgi?id=520685

Moreover, the backlog and plan for Platform 4.8 contains several possible other things LSP4E should use for better quality. We're only half-way to 4.8 since June, so imagine how can this list be in 6 more months. That's a lot of improvements and innovation we cannot delay to offer to our users IMO (at least, from our perspective at Red Hat, the value here is clearly worth not supporting older versions).

HTH