Community
Participate
Working Groups
Highlight information can currently be contributed from a plugin. This is done using a combination of two services: - 'orion.edit.model' allows the plugin to receive text change events from a TextView. - 'orion.edit.highlighter' allows the plugin to send styling information that will be applied to a TextView. The API here implicitly assumes that a plugin will deal with a single TextView. This assumption doesn't hold when (for example) you have 3 diff viewers that all want to be styled by the orion-codemirror plugin.
One way to fix this, in our current architecture, is to assign IDs to objects that a plugin is interested in, but that it cannot access directly. So we'd give a unique ID to every TextView, and then any API call that contains data from a TextView would include the TextView ID. For example, if you were writing a plugin that listened to a selection event, you would implement: onSelection(textViewId, selection) Rather than: onSelection(selection) The plugin would need to include this TextView ID in any data it sends back to Orion. If the plugin maintains any state between calls, it needs to store it per-TextView-instance so that one TextView cannot interfere with another. But this feels like a cumbersome workaround for not being able to pass a reference to the actual 'TextView' object to a plugin. I am worried that forcing this onto clients will make our APIs unpleasant to use.
I guess I'm searching for the equivalent of an executable extension from Eclipse desktop. A plugin wants to contribute an implementation of some interface. When the core needs the contribution, it magically instantiates it into a first-class object, and then interacts with it like any other object. This allows more encapsulation because there may be many instances of a contribution, each with its own separate internal state. By contrast, in our current architecture, Orion plugins are singletons. The services they contribute are also singletons. The core talks to these singletons to get work done, but every API call must carry all the parameters necessary to disambiguate one (would-be) instance of a contribution from another. Not sure if I'm explaining this very well, but hopefully the example in Comment 1 made it clear.
Yes it makes complete sense. Just to clarify though, on the "Coding" page there is only one text view so this isn't an issue right? I guess the problem would be compare pages, or git commit page, or any page showing multiple text views at once?
(In reply to comment #3) > Yes it makes complete sense. Just to clarify though, on the "Coding" page there > is only one text view so this isn't an issue right? I guess the problem would > be compare pages, or git commit page, or any page showing multiple text views > at once? Yes, that's right. If a service knows it will never apply to more than one thing on a page, there's no problem. But I can see a lot of the "coding-page only" services eventually being useful in compare & git-commit pages too -- for example, something like "mark occurrences".
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
