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