Hi Mark and Jonah,
I like the idea of having things more flexible on the hover, so, if Mark is
up to it, it would be a welcome addition.
Related to priorities, my feeling is that having explicit priorities in the
hover would be better ;)
Best Regards,
Fabio
On Wed, Jan 20, 2016 at 3:11 AM, Mark Leone <midnightj...@verizon.net>
wrote:
> Thanks for the helpful feedback, Jonah. I want to clarify that pull
> request 155 is unrelated to the issue discussed in this thread. It's just a
> simple implementation of a suggestion Fabio made to a question I asked in
> Stack Overflow ( http://stackoverflow.com/a/34788905/2036650). It
> addresses an issue I encountered wherein string and comment arguments have
> no hover behavior implemented.
>
> It seems quite likely that PR #155 implementation will be impacted by
> whatever is done for the larger issue of how to organize and prioritize
> hover participants. But since it was a simple change (and I wasn't aware of
> how the scope of this issue would expand), I went ahead with the pull
> request. I assume Fabio will take this discussion into account when he
> decides what to do with that pull request. And I will hold off on
> implementing anything for the larger issue until Fabio weighs in.
>
> But for my part, all your suggestions sound good to me. I think the
> preference page idea is a good one, and I also agree with providing all
> hover contributions via the extension point.
>
> One more clarification: when I referred to only one hover participant per
> plug-in being active, I was referring to what you described more
> appropriately, i.e. that only one participant will contribute info on a
> given hover event. In JDT, the hover participants are sorted in accordance
> with declaring plug-in dependency. So I believe two participants in the
> same plug-in would have a non-deterministic sort order, and the first one
> that is encountered and provides hover info would be the only one selected.
> With explicit hover priorities, the implementation could choose to combine
> hover info from multiple participants with the same priority value.
>
> -Mark
>
>
> On 1/19/16 7:01 PM, Jonah Graham wrote:
>
> PS, I would wait until Fabio provided some initial feedback before
> going gung-ho on this to make sure it lines up with his plans for
> PyDev.
> ~~~
> Jonah Graham
> Kichwa Coders Ltd.www.kichwacoders.com
>
>
> On 19 January 2016 at 23:59, Jonah Graham <jo...@kichwacoders.com>
> <jo...@kichwacoders.com> wrote:
>
> One thing on reviewing your pull request[1] I realized that for all
> audiences of this email that we are talking about pulling the
> extension point up a level, so that the extension point for Python
> hovers is for something of type ITextHover (of course you would need
> to maintain backwards compatibility and leave the existing extension
> point that uses IPyHoverParticipant, but that is an implementation
> issue to an extent).
>
> [1] https://github.com/fabioz/Pydev/pull/155
>
> Jonah
> ~~~
> Jonah Graham
> Kichwa Coders Ltd.www.kichwacoders.com
>
>
> On 19 January 2016 at 23:49, Jonah Graham <jo...@kichwacoders.com>
> <jo...@kichwacoders.com> wrote:
>
> 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-inhttps://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
>
>
> On 19 January 2016 at 23:06, Mark Leone <midnightj...@verizon.net>
> <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
> in 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
>
>
> On 19 January 2016 at 17:35, Mark Leone <midnightj...@verizon.net>
> <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
> listpydev-code@lists.sourceforge.nethttps://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
> listpydev-code@lists.sourceforge.nethttps://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
> listpydev-code@lists.sourceforge.nethttps://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
> listpydev-code@lists.sourceforge.nethttps://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
> 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
https://lists.sourceforge.net/lists/listinfo/pydev-code
