Re: [Pydev-code] Proposed change to Hover Participants
Brought to you by:
fabioz
Menu
▾
▴
Re: [Pydev-code] Proposed change to Hover Participants
|
From: Mark L. <mid...@ve...> - 2016-01-20 22:28:53
|
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 |
