Community
Participate
Working Groups
If we want to start supporting source hovers in the editor, there needs to be some kind of service that clients can extend. I propose orion.edit.hover. This service will provide the following: * hover index (index in the document that is currently being hovered over * current hover location (x, y coordinates) (maybe necessary, maybe not) The return value should be null if there is no hover and an HTML snippet if there is. This service should be attached to a content type. There also needs to be a way of handling situations where there are multiple hovers applicable at a given location. Perhaps handling could be arbitrary, or perhaps there could be a priority that is specified when registering the hover. It would also be nice if hovers were easy to make sticky somehow, so that if there is a link inside of the hover, then it could be easily clickable.
This would be a great addition to Orion. It would open doors to providing javadoc-style documentation hovers.
*** Bug 420085 has been marked as a duplicate of this bug. ***
*** Bug 420465 has been marked as a duplicate of this bug. ***
The main goal here should be to define the core service so that it can be used by the various language-specific plugins (JS, Java, Go, etc). A secondary goal is to create a JS implementation of this service. It looks like currently we do not have documentation in our type indexes. @mrennie I'm hoping you can point out the direction here - i.e., should type indexes start to incorporate documentation for functions and we display that comment only for types that have this available. This documentation information would also be valuable as additional information showing during content assist invocation but that is outside the scope of this bug. @maciej CCing you because we may also be able to make use of this in CF manifest editor (hover help for definition of manifest keys for example).
(In reply to John Arthorne from comment #4) > A secondary goal is to create a JS implementation of this service. It looks > like currently we do not have documentation in our type indexes. @mrennie > I'm hoping you can point out the direction here - i.e., should type indexes > start to incorporate documentation for functions and we display that comment > only for types that have this available. The indexes we use can easily incorporate doc - and originally do until we go through them and remove some unneeded entries. > This documentation information > would also be valuable as additional information showing during content > assist invocation but that is outside the scope of this bug. Tern already uses the doc information when creating the type indexes, which we in turn use in our environment. We also already use the doc in our inferencing.
(In reply to Michael Rennie from comment #5) I pushed an example implementation of JavaScript hover to: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=3f9d48cf50c651bb90f4a1dfa7381042b31cf262 once the framework-side changes are in for the service we can hook it up.
*** This bug has been marked as a duplicate of bug 445215 ***
Eric, any chance you could add support for HTML data (rather than MD or JSON) for the deferredInfo rendering logic in tooltip.js? (This is needed in the Flux project. JDT service can produce the HTML format Javadoc content and all that's needed at that point is embedding it into the tooltip's div)
Never mind. Looks like passing { title : htmlStr } would work for me.
