pydev-code

[Pydev-code] Proposed change to Hover Participants

[Mark L. <mid...@ve...>]

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

Re: [Pydev-code] Proposed change to Hover Participants

[Jonah G. <jo...@ki...>]

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 <mid...@ve...> 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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code

Re: [Pydev-code] Proposed change to Hover Participants

[Mark L. <mid...@ve...>]

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 <mid...@ve...> 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
>> pyd...@li...
>> 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
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code

Re: [Pydev-code] Proposed change to Hover Participants

[Jonah G. <jo...@ki...>]

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


On 19 January 2016 at 23:06, Mark Leone <mid...@ve...> 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 <mid...@ve...> 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
> pyd...@li...
> 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
> pyd...@li...
> 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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] Proposed change to Hover Participants

[Jonah G. <jo...@ki...>]

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...@ki...> 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-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
>
>
> On 19 January 2016 at 23:06, Mark Leone <mid...@ve...> 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 <mid...@ve...> 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
>> pyd...@li...
>> 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
>> pyd...@li...
>> 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
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>

Re: [Pydev-code] Proposed change to Hover Participants

[Jonah G. <jo...@ki...>]

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...@ki...> 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...@ki...> 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-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
>>
>>
>> On 19 January 2016 at 23:06, Mark Leone <mid...@ve...> 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 <mid...@ve...> 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
>>> pyd...@li...
>>> 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
>>> pyd...@li...
>>> 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
>>> pyd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>>

Re: [Pydev-code] Proposed change to Hover Participants

[Mark L. <mid...@ve...>]

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...@ki...> 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...@ki...> 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-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
>>>
>>>
>>> On 19 January 2016 at 23:06, Mark Leone <mid...@ve...> 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 <mid...@ve...> 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
>>>> pyd...@li...
>>>> 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
>>>> pyd...@li...
>>>> 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
>>>> pyd...@li...
>>>> 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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] Proposed change to Hover Participants

[Fabio Z. <fa...@es...>]

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 <mid...@ve...>
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...@ki...> <jo...@ki...> 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...@ki...> <jo...@ki...> 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 <mid...@ve...> <mid...@ve...> 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 <mid...@ve...> <mid...@ve...> 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 lis...@li...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 lis...@li...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 lis...@li...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 lis...@li...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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>

Re: [Pydev-code] Proposed change to Hover Participants

[Mark L. <mid...@ve...>]

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.

-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 <mid...@ve... 
> <mailto:mid...@ve...>> 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 <http://www.kichwacoders.com>
>>
>>
>>     On 19 January 2016 at 23:59, Jonah Graham<jo...@ki...> <mailto:jo...@ki...>  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 <http://www.kichwacoders.com>
>>>
>>>
>>>     On 19 January 2016 at 23:49, Jonah Graham<jo...@ki...> <mailto:jo...@ki...>  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-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<mid...@ve...> <mailto:mid...@ve...>  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<mid...@ve...> <mailto:mid...@ve...>  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
>>>>>     pyd...@li...
>>>>>     <mailto:pyd...@li...>
>>>>>     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
>>>>>     pyd...@li...
>>>>>     <mailto:pyd...@li...>
>>>>>     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
>>>>>     pyd...@li...
>>>>>     <mailto:pyd...@li...>
>>>>>     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
>>     pyd...@li...
>>     <mailto:pyd...@li...>
>>     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
>     pyd...@li...
>     <mailto:pyd...@li...>
>     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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code

Re: [Pydev-code] Proposed change to Hover Participants

[Fabio Z. <fa...@gm...>]

On Wed, Jan 20, 2016 at 8:28 PM, Mark Leone <mid...@ve...>
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 <mid...@ve...>
> 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...@ki...> <jo...@ki...> 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...@ki...> <jo...@ki...> 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 <mid...@ve...> <mid...@ve...> 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 <mid...@ve...> <mid...@ve...> 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 lis...@li...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 lis...@li...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 lis...@li...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 lis...@li...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
>> pyd...@li...
>> 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 lis...@li...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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>

Re: [Pydev-code] Proposed change to Hover Participants

[Mark L. <mid...@ve...>]

Here is the ticket for the hover participant enhancements:

https://sw-brainwy.rhcloud.com/tracker/PyDev/653

I developed the ideas discussed in this thread a bit further, so please 
take a look and provide any additional info, concerns, questions, etc. 
as comments on the ticket.

-Mark

On 01/21/2016 04:07 AM, Fabio Zadrozny wrote:
>
>
> On Wed, Jan 20, 2016 at 8:28 PM, Mark Leone <mid...@ve... 
> <mailto:mid...@ve...>> 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​

Re: [Pydev-code] Proposed change to Hover Participants

[Mark L. <mid...@ve...>]

I submitted a pull request for the hover participant re-factor: 
https://github.com/fabioz/Pydev/pull/159

Thanks, Jonah, for the suggestion about leveraging the JDT 
implementation. That was a big help. Here's a summary of the PyDev 
implementation:

- Deprecated the existing hover implementation, but left PyTextHover 
class and the pydev_hover extension point unchanged, for backward 
compatibility. If any contributions are made to pydev_hover, then 
everything works as before (docstring, marker, and participant hovers), 
and hovers registered with the new extension point are ignored. Thus 
existing clients won't break, but you have to break them if you want to 
use the new capability.

- PyTextHover class was re-factored into separate contributions to the 
new extension point for Docstring and Marker hover. So If no 
contributions are made to the deprecated extension point, Docstring and 
Marker hover (and debug hover) work just as before, but through the new 
extension point.

- The new extension point is pyTextHover. Contributions made to it by 
clients (as well as Docstring and Marker contributions to it built into 
PyDev) are configured on the PyDev -> Editor -> Hover preference page. 
You can enable hovers, set their priority, assign a modifier key (shift, 
alt, option, control) for when they are active, and specify preempt 
behavior for each hover.

- You can also select whether the highest priority hover is used, or if 
hovers are combined. If the latter, each enabled hover is consulted in 
descending priority order. If one is encountered with preempt set, then 
no lower priority hovers are included. An optional divider is placed 
between text from successive hovers.

- Clients can explicitly set the width of the hover control in pixels, 
if desired. This can be used to design hover text with deterministic 
line breaks, instead of having the framework insert breaks as needed to 
work with an automatically chosen control width.

- A separate extension point is provided to enable clients to contribute 
a custom combining hover. If nothing is contributed to it, the default 
combining behavior described above is used. No more than one 
implementation of a combining hover can be contributed by clients.

- Different behavior compared to JDT: 1) hovers sorted by assigned 
priority instead of plug-in dependency hierarchy. 2) Combining Hover 
instead of a Best Match Hover 3) Multiple hovers can be associated with 
the same modifier key, since the highest priority for a given modifier 
mask will be selected at run-time. 4) Combining behavior is specified 
with radio buttons, so the Combining Hover is not shown in the table.

I did my development with CentOS 6.7/gtk, and did some minimal testing 
on OSX (just to ensure no rendering issues). Hopefully others can do 
some testing in Windows, OSX, and other Linux distros. In particular, we 
need to make sure the check boxes in the preference table for the 
preempt column render properly. Eclipse doesn't support check boxes in 
table cells directly, so I used a pseudo-native rendering approach I 
found online. I had to tweak it a bit to get it to work properly on 
CentOS and OSX, so it would be good to verify it works on other platforms.

-Mark

On 1/21/16 4:07 AM, Fabio Zadrozny wrote:
>
>
> On Wed, Jan 20, 2016 at 8:28 PM, Mark Leone <mid...@ve... 
> <mailto:mid...@ve...>> 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
>>     <mid...@ve... <mailto:mid...@ve...>> 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 <http://www.kichwacoders.com>
>>>
>>>
>>>         On 19 January 2016 at 23:59, Jonah Graham<jo...@ki...> <mailto:jo...@ki...>  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 <http://www.kichwacoders.com>
>>>>
>>>>
>>>>         On 19 January 2016 at 23:49, Jonah Graham<jo...@ki...> <mailto:jo...@ki...>  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-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<mid...@ve...> <mailto:mid...@ve...>  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<mid...@ve...> <mailto:mid...@ve...>  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
>>>>>>         pyd...@li...
>>>>>>         <mailto:pyd...@li...>
>>>>>>         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
>>>>>>         pyd...@li...
>>>>>>         <mailto:pyd...@li...>
>>>>>>         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
>>>>>>         pyd...@li...
>>>>>>         <mailto:pyd...@li...>
>>>>>>         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
>>>         pyd...@li...
>>>         <mailto:pyd...@li...>
>>>         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
>>         pyd...@li...
>>         <mailto:pyd...@li...>
>>         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
>>     pyd...@li...
>>     <mailto:pyd...@li...>
>>     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
>     pyd...@li...
>     <mailto:pyd...@li...>
>     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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code

Re: [Pydev-code] Proposed change to Hover Participants

[Mark L. <mid...@ve...>]

I made a couple changes and pushed them:

1. I had neglected to include the extension point for a custom combining 
hover. It's ID is org.python.pydev.pydev_combiningHover

2. I renamed the new hover extension point to be consistent with the 
deprecated one. I renamed it from org.python.pydev.pyTextHover to 
org.python.pydev.pydev_hover2.

-Mark

On 02/11/2016 09:20 PM, Mark Leone wrote:
> I submitted a pull request for the hover participant re-factor: 
> https://github.com/fabioz/Pydev/pull/159
>
> Thanks, Jonah, for the suggestion about leveraging the JDT 
> implementation. That was a big help. Here's a summary of the PyDev 
> implementation:
>
> - Deprecated the existing hover implementation, but left PyTextHover 
> class and the pydev_hover extension point unchanged, for backward 
> compatibility. If any contributions are made to pydev_hover, then 
> everything works as before (docstring, marker, and participant 
> hovers), and hovers registered with the new extension point are 
> ignored. Thus existing clients won't break, but you have to break them 
> if you want to use the new capability.
>
> - PyTextHover class was re-factored into separate contributions to the 
> new extension point for Docstring and Marker hover. So If no 
> contributions are made to the deprecated extension point, Docstring 
> and Marker hover (and debug hover) work just as before, but through 
> the new extension point.
>
> - The new extension point is pyTextHover. Contributions made to it by 
> clients (as well as Docstring and Marker contributions to it built 
> into PyDev) are configured on the PyDev -> Editor -> Hover preference 
> page. You can enable hovers, set their priority, assign a modifier key 
> (shift, alt, option, control) for when they are active, and specify 
> preempt behavior for each hover.
>
> - You can also select whether the highest priority hover is used, or 
> if hovers are combined. If the latter, each enabled hover is consulted 
> in descending priority order. If one is encountered with preempt set, 
> then no lower priority hovers are included. An optional divider is 
> placed between text from successive hovers.
>
> - Clients can explicitly set the width of the hover control in pixels, 
> if desired. This can be used to design hover text with deterministic 
> line breaks, instead of having the framework insert breaks as needed 
> to work with an automatically chosen control width.
>
> - A separate extension point is provided to enable clients to 
> contribute a custom combining hover. If nothing is contributed to it, 
> the default combining behavior described above is used. No more than 
> one implementation of a combining hover can be contributed by clients.
>
> - Different behavior compared to JDT: 1) hovers sorted by assigned 
> priority instead of plug-in dependency hierarchy. 2) Combining Hover 
> instead of a Best Match Hover 3) Multiple hovers can be associated 
> with the same modifier key, since the highest priority for a given 
> modifier mask will be selected at run-time. 4) Combining behavior is 
> specified with radio buttons, so the Combining Hover is not shown in 
> the table.
>
> I did my development with CentOS 6.7/gtk, and did some minimal testing 
> on OSX (just to ensure no rendering issues). Hopefully others can do 
> some testing in Windows, OSX, and other Linux distros. In particular, 
> we need to make sure the check boxes in the preference table for the 
> preempt column render properly. Eclipse doesn't support check boxes in 
> table cells directly, so I used a pseudo-native rendering approach I 
> found online. I had to tweak it a bit to get it to work properly on 
> CentOS and OSX, so it would be good to verify it works on other platforms.
>
> -Mark
>
> On 1/21/16 4:07 AM, Fabio Zadrozny wrote:
>>
>>
>> On Wed, Jan 20, 2016 at 8:28 PM, Mark Leone <mid...@ve... 
>> <mailto:mid...@ve...>> 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
>>>     <mid...@ve...> 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 <http://www.kichwacoders.com>
>>>>
>>>>
>>>>         On 19 January 2016 at 23:59, Jonah Graham<jo...@ki...> <mailto:jo...@ki...>  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 <http://www.kichwacoders.com>
>>>>>
>>>>>
>>>>>         On 19 January 2016 at 23:49, Jonah Graham<jo...@ki...> <mailto:jo...@ki...>  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-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<mid...@ve...> <mailto:mid...@ve...>  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<mid...@ve...> <mailto:mid...@ve...>  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
>>>>>>>         pyd...@li...
>>>>>>>         <mailto:pyd...@li...>
>>>>>>>         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
>>>>>>>         pyd...@li...
>>>>>>>         <mailto:pyd...@li...>
>>>>>>>         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
>>>>>>>         pyd...@li...
>>>>>>>         <mailto:pyd...@li...>
>>>>>>>         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
>>>>         pyd...@li...
>>>>         <mailto:pyd...@li...>
>>>>         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
>>>         pyd...@li...
>>>         <mailto:pyd...@li...>
>>>         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
>>>     pyd...@li...
>>>     <mailto:pyd...@li...>
>>>     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
>>     pyd...@li...
>>     <mailto:pyd...@li...>
>>     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
>> pyd...@li...
>> 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=272487151&iu=/4140
>
>
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code