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-02-12 18:04:58
|
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 |
