Summary: | Asynchronous & non-blocking hyperlink detection | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Michal Niewrzal <wywrzal> |
Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | azerr, daniel_megert, gautier.desaintmartinlacaze, jcompagner, mistria, mlippert |
Version: | 4.6 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=508457 https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/173318 https://git.eclipse.org/r/c/lsp4e/lsp4e/+/173319 |
||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 561372 |
Description
Michal Niewrzal
2016-10-24 16:25:28 EDT
It should really fantastic if we could have an async hyperlink detector which could work with CompletableFuture by providing an interface like this: ---------------------------------- public interface IAsyncHyperlinkDetector { CompletableFuture<IHyperlink[]> detectHyperlinks(ITextViewer textViewer, IRegion region, boolean canShowMultipleHyperlinks); } ---------------------------------- *** Bug 569402 has been marked as a duplicate of this bug. *** New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/173318 New Gerrit change created: https://git.eclipse.org/r/c/lsp4e/lsp4e/+/173319 i made a patch for platform.text and a small patch for this that works with it With this first cut (as an idea) it already works its fully async and a small patch for: https://bugs.eclipse.org/bugs/show_bug.cgi?id=561372 i updated the patch so it doesn't break api and now the extension point will way if it is async or not so we can upfront create the right delegates i didn't change it yet to Flow.Publisher/Subscriber. will have a look at that later The detection strategies are implemented, except that "first" only works currently with the default "sync" operation not with the async api. Maybe if we are Publish/Subscibe that can be also implemented easier. (i guess with the current futures this should be also possible, the first future that returns is leading?) I guess that first is really an optimization to get as quickly a result in the event thread.. it doesn't matter to much now i guess. Except if one really takes long... now everything waits for it. i made a new patch (and something did go wrong with the changeid, because i needed to revert some stuff first) https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/175291 |