On Wed, Jan 20, 2016 at 8:28 PM, Mark Leone <midnightj...@verizon.net>
wrote:

> Thanks, Fabio. I'm ready to start work on it now. Would it be OK to create
> an issue on the PyDev tracker for this? If so, should I assign it to group
> New:Accepted? I thought it might be useful to put a summary of the approach
> there, consolidated from this thread, so I can more easily get further
> feedback on the implementation if needed.
>

​Sure... just create it and I'll move it to "Current: planned for next
release" ;)

Best Regards,

Fabio​



>
>
> -Mark
>
>
> On 01/20/2016 06:00 AM, Fabio Zadrozny wrote:
>
> 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>
>> 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 
> 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

Reply via email to