Hi Mark,
Thanks, Jonah. That's very helpful.
No problem, here is some more input.
I see that the JDT implementation
determines the priority of the hover participants in accordance with the
dependency hierarchy of the respective contributing plug-ins. I'd like to
get get your opinion (or others) on the usefulness of declaring priorities
explicitly as I described.
It seems to me explicit priorities have some significant advantages,
you wouldn't have declare order priorities and would not need a
comment like "<!-- Note: Do not change the sequence of those hover
contributions -->" [1].
One advantage of that is that you could enable
multiple participants to be active by assigning identical priorities.
The participants that are active are all the participants installed in
the active plug-ins that are enabled by the user. The priorities does
not limit them being active, just which one gets chosen for a
particular hover job. The BestMatchHover then iterates through all of
these in sorted order until the first one that returns an actual
hover.
This of course relies on having a BestMatchHover for PyDev and when it
is enabled it is the hover provider in use. The BestMatchHover should
typically be highest priority (but someone could write a higher
priority one, that like BestMatchHover delegated to other hovers)
It looks like in the JDT implementation the assumption is that no more than
one
participant will be declared per plug-in, so you cannot have more than one
participant contribute hover info.
The standard JDT hovers are all in the one plug-in [1] except the
debug ones which are contributed by debug plug-in.
It also seems more useful to me to
control the priority explicitly, rather than have it follow the plug-in
dependency hierarchy. You may have a plug-in which doesn't override other
plug-in behavior but whose hover nevertheless needs to override other
hovers. Or maybe that's not very likely. I don't have an actual use case in
mind.
I ran into an actual use case a while ago for a customer. I needed to
provide a special hover under some condition[2], but it was not
possible to make my hover higher priority with the current scheme. So
as this was a fully custom IDE, I put a workaround[3] to prioritise my
hover above the natural order they are discovered in. So yes a vote
for explicit priorities. I suspect if someone wrote a patch for JDT
for explicit priorities (with a reasonable default) it would be
accepted. Such an improvement would be nice with a preference page
that simply allowed sorting them in the right order too BTW.
Also there doesn't seem to be in JDT the PyDev equivalent of TextHover
implementations separate from those declared via hover participant
extensions (i.e. marker hover and docstring hover as invoked in
PyTextHover). So the PyDev implementation will be different at least on that
score.
This is a case where I think that part of PyDev needs to be changed if
you adopt your solution. All the hovers should be declared through the
extension point, only the extension point declared priority makes the
PyDev built-in one more important (unless your third-party one is even
higher priority of course, and through the preference page a user can
disable your one!). PyDev has its hover hardcoded (as you know, but
others reading may not) in the extended TextSourceViewerConfiguration
[4] but the JDT uses the hover that comes from the extension point [5]
[1]https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/org.eclipse.jdt.ui/plugin.xml#n473
[2] The customer wanted some special API documentation to be showed if
specific symbols were hovered over. Not a general use case, but it was
annoying the API did not allow me to do it.
[3] by modifying the sorter in the plug-in
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/JavaPlugin.java#n783
that way the combined hover would see my special one ahead of the
standard one.
[4]https://github.com/fabioz/Pydev/blob/development/plugins/org.python.pydev/src/org/python/pydev/editor/PyEditConfiguration.java#L74
[5]https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/text/JavaSourceViewerConfiguration.java#n673
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com <http://www.kichwacoders.com>
On 19 January 2016 at 23:06, Mark Leone<midnightj...@verizon.net>
<mailto:midnightj...@verizon.net> wrote:
Thanks, Jonah. That's very helpful. I see that the JDT implementation
determines the priority of the hover participants in accordance with the
dependency hierarchy of the respective contributing plug-ins. I'd like to
get get your opinion (or others) on the usefulness of declaring priorities
explicitly as I described. One advantage of that is that you could enable
multiple participants to be active by assigning identical priorities. It
looks like in the JDT implementation the assumption is that no more than one
participant will be declared per plug-in, so you cannot have more than one
participant contribute hover info. It also seems more useful to me to
control the priority explicitly, rather than have it follow the plug-in
dependency hierarchy. You may have a plug-in which doesn't override other
plug-in behavior but whose hover nevertheless needs to override other
hovers. Or maybe that's not very likely. I don't have an actual use case in
mind.
Also there doesn't seem to be in JDT the PyDev equivalent of TextHover
implementations separate from those declared via hover participant
extensions (i.e. marker hover and docstring hover as invoked in
PyTextHover). So the PyDev implementation will be different at least on that
score.
-Mark
On 01/19/2016 01:25 PM, Jonah Graham wrote:
HI Mark,
To me it sounds like you are on the right track.
What I recommend in addition is you consider reusing JDT's Hover code
as it already has a lot of that logic. You may want to copy the code
as I believe that is what CDT did for the same feature and I wouldn't
be suprised if other language tools have too. I think there is a bug
inbugs.eclipse.org <http://bugs.eclipse.org> about moving the
functionality from JDT to
platform to make it easier to reused, but I couldn't find it.
This is the JDT extension point:
http://help.eclipse.org/mars/topic/org.eclipse.jdt.doc.isv/reference/extension-points/org_eclipse_jdt_ui_javaEditorTextHovers.html?cp=3_1_1_31
This is the CDT one:
http://help.eclipse.org/mars/topic/org.eclipse.cdt.doc.isv/reference/extension-points/org_eclipse_cdt_ui_textHovers.html?cp=14_1_1_39
And then there is a "meta" hover called the combined hover that
chooses the best other hover installed to display:
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/text/java/hover/BestMatchHover.java
The preferences UI (see attached screenshot, but I am sure you can
find it in your Eclipse too) is for controlling and overriding:
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/preferences/JavaEditorHoverPreferencePage.java
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com <http://www.kichwacoders.com>
On 19 January 2016 at 17:35, Mark Leone<midnightj...@verizon.net>
<mailto:midnightj...@verizon.net> wrote:
I'm making a change to PyDev and will submit a pull request if
appropriate. But I'd like to know if there's a better way to do what I'm
trying to do, or if the behavior I'm after is not of general interest.
The issue I'm having is that I implemented a hover participant, and I'd
like it to preempt the TextHover contributions from PyDev when it has
something to contribute. This was a simple change, including the
addition of a preference to toggle the behavior of ignoring PyDev's
TextHover info when one or more hover participants contributes hover info.
However, it seems I should probably make a more general mod as well,
even though the above meets my current use case. What I have in mind is
to add two attributes to the hover participant extension point. One
attribute is an integer that specifies priority, and the other is a
boolean that specifies whether or not to preempt PyDev's built-in
TextHover. The behavior will be that registered hover participants will
be called in decreasing priority order, and as soon as one contributes
hover info, the remaining participants are not invoked. If any
participant contributes hover info, the built-in PyDev TextHover will be
invoked subsequently only if the aforementioned boolean attribute for
the contributing participant specifies that PyDev TextHover should not
be ignored.
Does this make sense? Is there a better way to approach it? Is this
behavior of general interest?
-Mark
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
pydev-code mailing list
pydev-code@lists.sourceforge.net
<mailto:pydev-code@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pydev-code
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
pydev-code mailing list
pydev-code@lists.sourceforge.net
<mailto:pydev-code@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pydev-code
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
pydev-code mailing list
pydev-code@lists.sourceforge.net
<mailto:pydev-code@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pydev-code
