Re: [Pydev-code] Proposed change to Hover Participants
Brought to you by:
fabioz
Menu
▾
▴
Re: [Pydev-code] Proposed change to Hover Participants
|
From: Fabio Z. <fa...@gm...> - 2016-01-21 09:08:22
|
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 > > |
