Community
Participate
Working Groups
There should be a generic hover help preference page for all text editors. It can behave somewhat like the Annotations preference page where editors can add their list of annotations but for hovers, they can add their own types of hovers. This way, there is a common way to get hover preferences and to change them. There can also be generic hover types where the hover info varies based on content type. For example, there can be a Documentation hover. For Java, documentation might mean the JavaDoc. For XML, it might mean any documentation provided by the associated schema. Source hover would be another generic type. Editors can look up what types of hover preferences are enabled and their state mask, and see if they can honor the hover type enabled. For example, the Text editor could check if Annotation hover is currently enabled, if so, it can show hover help for all annotations shown in text (including bookmarks, tasks)
Clients of java editor can use org.eclipse.jdt.ui.javaEditorTextHovers to contribute their own text hovers. It would be good to push this down to the base text editor. And then you could add the ability for multiple clients to specify different ITextHovers based on partition type (or maybe it's easier to start with content type) for the same hover type. For example, to go back to the Documentation hover. There could be a documentation hover type. And Java could contribute their javadoc ITextHover for documentation hover in java regions. And xml could contribute their schema documentation ITextHover for documentation hover in xml regions. The extension point could look something like this (mainly copied from org.eclipse.jdt.ui.javaEditorTextHovers): <!ELEMENT extension (hover*)> <!ATTLIST extension point CDATA #REQUIRED id CDATA #IMPLIED name CDATA #IMPLIED> <!ELEMENT hover EMPTY> <!ATTLIST hover id CDATA #REQUIRED class CDATA #REQUIRED label CDATA #IMPLIED description CDATA #IMPLIED activate (true | false) "false" type CDATA #IMPLIED contentType/partitionType CDATA #IMPLIED > type would be the id of another hover definition that the current hover would override and content type/partition type would be which content type/partition type the hover would apply to
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
