Re: [Pydev-code] Proposed change to Hover Participants
Brought to you by:
fabioz
From: Jonah G. <jo...@ki...> - 2016-01-20 00:00:35
|
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 >> |