pydev-code Mailing List for PyDev for Eclipse (Page 5)
Brought to you by:
fabioz
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(14) |
Apr
(18) |
May
(12) |
Jun
(34) |
Jul
(31) |
Aug
(37) |
Sep
(22) |
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(1) |
Feb
(4) |
Mar
(9) |
Apr
(1) |
May
|
Jun
(2) |
Jul
(24) |
Aug
(3) |
Sep
(5) |
Oct
(3) |
Nov
(3) |
Dec
(5) |
2006 |
Jan
(5) |
Feb
(23) |
Mar
(5) |
Apr
(80) |
May
(26) |
Jun
(13) |
Jul
(13) |
Aug
(4) |
Sep
(31) |
Oct
(24) |
Nov
(6) |
Dec
(2) |
2007 |
Jan
(7) |
Feb
|
Mar
(26) |
Apr
(3) |
May
(8) |
Jun
(6) |
Jul
(11) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(9) |
Dec
(3) |
2008 |
Jan
(7) |
Feb
(1) |
Mar
(6) |
Apr
(7) |
May
(9) |
Jun
(14) |
Jul
(9) |
Aug
(6) |
Sep
(10) |
Oct
(5) |
Nov
(8) |
Dec
(5) |
2009 |
Jan
(8) |
Feb
(10) |
Mar
(10) |
Apr
(1) |
May
(3) |
Jun
(5) |
Jul
(10) |
Aug
(3) |
Sep
(12) |
Oct
(6) |
Nov
(22) |
Dec
(12) |
2010 |
Jan
(10) |
Feb
(17) |
Mar
(5) |
Apr
(9) |
May
(8) |
Jun
(2) |
Jul
(4) |
Aug
(12) |
Sep
(1) |
Oct
(1) |
Nov
(8) |
Dec
|
2011 |
Jan
(14) |
Feb
(8) |
Mar
(3) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
(10) |
Aug
(7) |
Sep
|
Oct
(4) |
Nov
(4) |
Dec
(8) |
2012 |
Jan
|
Feb
(8) |
Mar
(10) |
Apr
(5) |
May
(4) |
Jun
(10) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(11) |
Nov
(1) |
Dec
|
2013 |
Jan
(1) |
Feb
(2) |
Mar
(11) |
Apr
(10) |
May
(7) |
Jun
(9) |
Jul
(13) |
Aug
(20) |
Sep
(4) |
Oct
(18) |
Nov
(5) |
Dec
(7) |
2014 |
Jan
(3) |
Feb
(5) |
Mar
(7) |
Apr
(5) |
May
(10) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(7) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2015 |
Jan
(1) |
Feb
(1) |
Mar
(8) |
Apr
(3) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(3) |
Nov
(5) |
Dec
(1) |
2016 |
Jan
(26) |
Feb
(10) |
Mar
(4) |
Apr
|
May
(4) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(3) |
2017 |
Jan
(3) |
Feb
|
Mar
(9) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(9) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2018 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
(3) |
2019 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(11) |
2021 |
Jan
(3) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2024 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jonah G. <jo...@ki...> - 2016-02-29 22:30:19
|
Number 3 was supposed to read 3) The feature xml often has "unpack" attribute omitted which then comes to the default of *true*. On Monday, 29 February 2016, Jonah Graham <jo...@ki...> wrote: > Hi Mark, > > I don't have access to try before I send this to you. But a few pointers > that may or may not help (including some duplication of what you have > already figured out): > > 1) The jar in the P2 site should be a jar, the p2 install process should > explode it. You may be missing the "install" step depending on how you have > your target platform set up. > 2) Check shape of the bundle is dir (in manifest, the Eclipse-BundleShape > directive) > http://help.eclipse.org/mars/topic/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html?cp=2_1_5_10 > 3) The feature xml often has "unpack" attribute omitted which then comes > to the default of false. > 4) The Jython addon for Eclipse EASE also includes jython.jar exploded, so > it may be a useful checkpoint (I am not recommending using that version, > but comparing against it may be useful). > Source: https://github.com/eclipse-ease-addons/jython > p2 site: https://dl.bintray.com/pontesegger/ease-jython/ > > PS I am very curious what you are building with all these great changes, I > hope you can let us curious people know when it is ready. > > Jonah > > > > ~~~ > Jonah Graham > Kichwa Coders Ltd. > www.kichwacoders.com > > On 29 February 2016 at 21:52, Mark Leone <mid...@ve... > <javascript:_e(%7B%7D,'cvml','mid...@ve...');>> wrote: > >> I'm doing a PyDev build so I can incorporate a modified version of PyDev >> in my app which I'm releasing today. I add the generated p2 repo to my >> target platform, but when I launch the runtime workbench I get lots of >> errors because apparently the org.python.pydev.jython bundle needs to be >> exploded rather than in jar form. (the error message is "Can't find >> relative path:. within:org.python.pydev.jython_4.5.2.201602292131 [710]") >> >> The maven pom file seems to be configured to explode all bundles. I also >> tried adding unpack="true" for org.python.pydev.jython in feature.xml. >> Still the p2 site is created with jar files. Does anyone know how I can >> create a p2 site with exploded bundles, or at least the jython bundle >> exploded? >> >> -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=272487151&iu=/4140 >> _______________________________________________ >> pydev-code mailing list >> pyd...@li... >> <javascript:_e(%7B%7D,'cvml','pyd...@li...');> >> https://lists.sourceforge.net/lists/listinfo/pydev-code >> > > -- ~~~ Jonah Graham Kichwa Coders Ltd. www.kichwacoders.com |
From: Mark L. <mid...@ve...> - 2016-02-29 21:52:27
|
I'm doing a PyDev build so I can incorporate a modified version of PyDev in my app which I'm releasing today. I add the generated p2 repo to my target platform, but when I launch the runtime workbench I get lots of errors because apparently the org.python.pydev.jython bundle needs to be exploded rather than in jar form. (the error message is "Can't find relative path:. within:org.python.pydev.jython_4.5.2.201602292131 [710]") The maven pom file seems to be configured to explode all bundles. I also tried adding unpack="true" for org.python.pydev.jython in feature.xml. Still the p2 site is created with jar files. Does anyone know how I can create a p2 site with exploded bundles, or at least the jython bundle exploded? -Mark |
From: Mark L. <mid...@ve...> - 2016-02-26 17:47:52
|
I found where PyDev is doing the magic, in PyLinkedModeCompletionProposal. I made my own copy of this class, modifying the goToLinkedModeFromArgs() method to parse my arg string. It has parameter names and values (i.e. somename=someVal), and I want the editable fields to be just the param values. -Mark On 02/26/2016 12:28 AM, Mark Leone wrote: > I've implemented some custom code completion with a completion > participant. When I apply one of the completions, I want to make the > method arguments easy to edit, the same way that JDT and PyDev do. That > is, a border style is set for each arg, and the first one is highlighted > with the carrot positioned at the beginning. > > I have this working, but it's clunky. I'm setting styles on the > StyledText widget for each argument. At first I did it with a > LineStyleListener, but this blows away PyDev's syntax hightlighting. I > had hoped that its styling was done with a LineStyleListener, but I see > that it's not. Therefore I have to set the styles directly. I do that as > soon as the completion proposal is selected. > > However, shortly after I set the styles to highlight the args, a parse > occurs and my styles are wiped out. I implemented a PostParseListener > top put them back. That works, but it looks terrible because the styles > appear, disappear almost immediately, and then re-appear a second or two > later. > > The defaul PyDev completion processor does this smoothly, but I looked > all through the code and I can't see where it happens. Can someone tell > me what the right way is to handle what I'm trying to do, or point me to > the PyDev code that does it so I can follow that example? > > -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=272487151&iu=/4140 > _______________________________________________ > pydev-code mailing list > pyd...@li... > https://lists.sourceforge.net/lists/listinfo/pydev-code > |
From: Mark L. <mid...@ve...> - 2016-02-26 05:28:20
|
I've implemented some custom code completion with a completion participant. When I apply one of the completions, I want to make the method arguments easy to edit, the same way that JDT and PyDev do. That is, a border style is set for each arg, and the first one is highlighted with the carrot positioned at the beginning. I have this working, but it's clunky. I'm setting styles on the StyledText widget for each argument. At first I did it with a LineStyleListener, but this blows away PyDev's syntax hightlighting. I had hoped that its styling was done with a LineStyleListener, but I see that it's not. Therefore I have to set the styles directly. I do that as soon as the completion proposal is selected. However, shortly after I set the styles to highlight the args, a parse occurs and my styles are wiped out. I implemented a PostParseListener top put them back. That works, but it looks terrible because the styles appear, disappear almost immediately, and then re-appear a second or two later. The defaul PyDev completion processor does this smoothly, but I looked all through the code and I can't see where it happens. Can someone tell me what the right way is to handle what I'm trying to do, or point me to the PyDev code that does it so I can follow that example? -Mark |
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 |
From: Mark L. <mid...@ve...> - 2016-02-12 02:21:51
|
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... <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... >> <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 |
From: Mark L. <mid...@ve...> - 2016-02-01 17:24:22
|
I just created a Pull request for this. No need to do anything with it until you get back. See PR comment about whether any change was needed for the Windows property file (I assumed no). I just added the additional property to the linux and travis properties files, and modified TestDependent.GetCompletePythonLib() to include the extra property if specified. This fixes the problem I was seeing, but if there's somewhere else in the code that needs to be modified, just let me know. -Mark On 01/30/2016 02:25 PM, Fabio Zadrozny wrote: > It should be customized as the other test related constants (in the > TestDependent.XXXX files and it should go along in the env in the > place that does the launch). > > As a note, I'm going to take 2 weeks off starting Feb 1st... I may > still answer things during the period, but probably will take longer > to answer. > > Best Regards, > > Fabio > > On Sat, Jan 30, 2016 at 1:12 PM, Mark Leone <mid...@ve... > <mailto:mid...@ve...>> wrote: > > Sure, I'll be glad to do that. I may have a question abut exactly > where to insert the code. I'll let you know when I get back to the > office on Monday and have a look at the code base. > > -Mark > > On 1/30/16 7:42 AM, Fabio Zadrozny wrote: >> I think that we should probably have an PYTHON_LIB_DYNLOAD which >> we'd also configure to add to the tests in this case (and when >> running, we'd also add that dir to the PYTHONPATH if it's specified). >> >> As you can reproduce the error there, do you think you could >> change that? >> >> Best Regards, >> >> Fabio >> > > > ------------------------------------------------------------------------------ > 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 |
From: Fabio Z. <fa...@gm...> - 2016-01-30 19:26:07
|
It should be customized as the other test related constants (in the TestDependent.XXXX files and it should go along in the env in the place that does the launch). As a note, I'm going to take 2 weeks off starting Feb 1st... I may still answer things during the period, but probably will take longer to answer. Best Regards, Fabio On Sat, Jan 30, 2016 at 1:12 PM, Mark Leone <mid...@ve...> wrote: > Sure, I'll be glad to do that. I may have a question abut exactly where to > insert the code. I'll let you know when I get back to the office on Monday > and have a look at the code base. > > -Mark > > On 1/30/16 7:42 AM, Fabio Zadrozny wrote: > > I think that we should probably have an PYTHON_LIB_DYNLOAD which we'd also > configure to add to the tests in this case (and when running, we'd also add > that dir to the PYTHONPATH if it's specified). > > As you can reproduce the error there, do you think you could change that? > > Best Regards, > > Fabio > > > > > ------------------------------------------------------------------------------ > 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 > > |
From: Mark L. <mid...@ve...> - 2016-01-30 15:12:47
|
Sure, I'll be glad to do that. I may have a question abut exactly where to insert the code. I'll let you know when I get back to the office on Monday and have a look at the code base. -Mark On 1/30/16 7:42 AM, Fabio Zadrozny wrote: > I think that we should probably have an PYTHON_LIB_DYNLOAD which we'd > also configure to add to the tests in this case (and when running, > we'd also add that dir to the PYTHONPATH if it's specified). > > As you can reproduce the error there, do you think you could change that? > > Best Regards, > > Fabio > |
From: Fabio Z. <fa...@gm...> - 2016-01-30 12:42:46
|
I think that we should probably have an PYTHON_LIB_DYNLOAD which we'd also configure to add to the tests in this case (and when running, we'd also add that dir to the PYTHONPATH if it's specified). As you can reproduce the error there, do you think you could change that? Best Regards, Fabio On Mon, Jan 25, 2016 at 6:56 PM, Mark Leone <mid...@ve...> wrote: > Stepping through the code it seems that it adds PYTHONPATH entries only > for the values of the PYTHON_LIB and PYTHON_SITE_PACKAGES properties (and > the specific package dependencies, such as wxPython, numpy, etc) in > TestDependent.<os>.properties. It doesn't parse any xxx.pth entries in > those locations as python does. And it sets the infos on the default > interpreter only with the directories explicitly set in the properties > file. Unless I'm missing some other way to specify that, this seems to be a > bug. > > To make it work, I created a symlink in the location pointed to by > PYTHON_LIB, which links to the mathmodule.so file in > /usr/lib64/lib-dynload. This directory shows up as a lib entry in the > python interpreter in PyDev preference page (even without the math.pth file > pointing to it). But it's not being added to PYTHONPATH by the test code. > Can the test code be made to use the configured PyDev interpreter instead > of creating a default one with a limited set of PYTHONPATH entries? Or is > there some way to make the default interpreter parse the xxx.pth files at > all the PYTHONPATH locations? > > I don't know why on my CentOS system I have this lib-dynload directory as > a sibling to the python library directory, but python seems to be > configured to recognize it. > > -Mark > > On 01/25/2016 02:19 PM, Mark Leone wrote: > > Further on this: adding the line > > pythonpath.add("/usr/lib64/python2.6/lib-dynload/"); > > to the beginning of AbsrtactShell.Tuple() makes the test succeed. > Obviously not the right solution, but it seems to demonstrate that my > PYTHONPATH setup is the problem. I don;t know why setting it in the > Environment tab of the run config doesn't have any effect. > > > > > ------------------------------------------------------------------------------ > 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 > > |
From: Fabio Z. <fa...@gm...> - 2016-01-27 13:27:01
|
PyVmMonitor 1.0.1 is now available for download *Release Highlights:* - Pstats files may be passed in the command line to be opened in pyvmmonitor-ui. - Fixed issue opening PyVmMonitor in Mac OS (El Capitan). - Opening PStats file may fail because it's linked to a Python version, so, in such a situation, PyVmMonitor allows opening it using a different interpreter. - Command line examples are properly wrapped with quotes on Windows. See: http://www.pyvmmonitor.com for more information. *What is PyVmMonitor?* PyVmMonitor is a profiler with a simple goal: being the best way to profile a Python program. *Features* - Attach profiler to a running (CPython) program - Deterministic profiling through cProfile/profile integration - On demand profiling with Yappi integration - Analyze existing PStats results - Open DOT files - Programatic API access - Profile on a different machine - Multiple processes support (multiprocessing, django...) - Live sampling/CPU view - Select time range - Group samples by method or line - PyDev integration - PyCharm integration Enjoy! Fabio Zadrozny Software Developer LiClipse http://www.liclipse.com PyDev - Python Development Environment for Eclipse http://pydev.org http://pydev.blogspot.com PyVmMonitor - Python Profiler http://www.pyvmmonitor.com/ |
From: Patrick W. <pwi...@co...> - 2016-01-26 07:31:55
|
Please take out of this list. > Am 25.01.2016 um 21:56 schrieb Mark Leone <mid...@ve...>: > > Stepping through the code it seems that it adds PYTHONPATH entries only for the values of the PYTHON_LIB and PYTHON_SITE_PACKAGES properties (and the specific package dependencies, such as wxPython, numpy, etc) in TestDependent.<os>.properties. It doesn't parse any xxx.pth entries in those locations as python does. And it sets the infos on the default interpreter only with the directories explicitly set in the properties file. Unless I'm missing some other way to specify that, this seems to be a bug. > > To make it work, I created a symlink in the location pointed to by PYTHON_LIB, which links to the mathmodule.so file in /usr/lib64/lib-dynload. This directory shows up as a lib entry in the python interpreter in PyDev preference page (even without the math.pth file pointing to it). But it's not being added to PYTHONPATH by the test code. Can the test code be made to use the configured PyDev interpreter instead of creating a default one with a limited set of PYTHONPATH entries? Or is there some way to make the default interpreter parse the xxx.pth files at all the PYTHONPATH locations? > > I don't know why on my CentOS system I have this lib-dynload directory as a sibling to the python library directory, but python seems to be configured to recognize it. > > -Mark > > On 01/25/2016 02:19 PM, Mark Leone wrote: >> Further on this: adding the line >> >> pythonpath.add("/usr/lib64/python2.6/lib-dynload/"); >> >> to the beginning of AbsrtactShell.Tuple() makes the test succeed. Obviously not the right solution, but it seems to demonstrate that my PYTHONPATH setup is the problem. I don;t know why setting it in the Environment tab of the run config doesn't have any effect. >> > > ------------------------------------------------------------------------------ > 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 |
From: Mark L. <mid...@ve...> - 2016-01-25 20:56:58
|
Stepping through the code it seems that it adds PYTHONPATH entries only for the values of the PYTHON_LIB and PYTHON_SITE_PACKAGES properties (and the specific package dependencies, such as wxPython, numpy, etc) in TestDependent.<os>.properties. It doesn't parse any xxx.pth entries in those locations as python does. And it sets the infos on the default interpreter only with the directories explicitly set in the properties file. Unless I'm missing some other way to specify that, this seems to be a bug. To make it work, I created a symlink in the location pointed to by PYTHON_LIB, which links to the mathmodule.so file in /usr/lib64/lib-dynload. This directory shows up as a lib entry in the python interpreter in PyDev preference page (even without the math.pth file pointing to it). But it's not being added to PYTHONPATH by the test code. Can the test code be made to use the configured PyDev interpreter instead of creating a default one with a limited set of PYTHONPATH entries? Or is there some way to make the default interpreter parse the xxx.pth files at all the PYTHONPATH locations? I don't know why on my CentOS system I have this lib-dynload directory as a sibling to the python library directory, but python seems to be configured to recognize it. -Mark On 01/25/2016 02:19 PM, Mark Leone wrote: > Further on this: adding the line > > pythonpath.add("/usr/lib64/python2.6/lib-dynload/"); > > to the beginning of AbsrtactShell.Tuple() makes the test succeed. > Obviously not the right solution, but it seems to demonstrate that my > PYTHONPATH setup is the problem. I don;t know why setting it in the > Environment tab of the run config doesn't have any effect. > |
From: Mark L. <mid...@ve...> - 2016-01-25 19:19:20
|
Further on this: adding the line pythonpath.add("/usr/lib64/python2.6/lib-dynload/"); to the beginning of AbsrtactShell.Tuple() makes the test succeed. Obviously not the right solution, but it seems to demonstrate that my PYTHONPATH setup is the problem. I don;t know why setting it in the Environment tab of the run config doesn't have any effect. -Mark On 01/25/2016 02:02 PM, Mark Leone wrote: >> >> >> A failure I don't expect: >> >> In PythonShellTest at line 95, and IndexOutOfBounds exception is >> thrown. >> The "list" object is empty, apparently because the import for the >> "math" >> module fails. I believe I have all the python locations and files >> specified properly, and if I launch a python shell manually, I can >> successfully import the math module. >> >> >> Well, I don't have that failure here, so, it really seems >> unexpected, although it's hard to know why without further details -- >> it probably means you have some issue communicating with the shell >> (so, maybe you could try debugging it there?) > > In the debugger I see that it fails to import the math module. If I'm > reading the stack trace correctly, the directories on sys.path are > > ['/opt/git/Pydev/plugins/org.python.pydev/tests/pysrc', > '/usr/lib64/python2.6', '/usr/lib64/python2.6/site-packages', > '/usr/lib/python2.6/site-packages/OpenGL'] > > When I launch a python 2.6 shell, I can import math successfully, and > 'math.__file__' returns /usr/lib64/python2.6/lib-dynload/mathmodule.so > > So it seems I need to add "/usr/lib64/python2.6/lib-dynload" to > sys.path. I tried doing that by creating a file > /usr/lib64/python2.6/site-packages/math.pth (the value of > PYTHON_SITE_PACKAGES in TestDepedendent.linux.properties is > /usr/lib64/python2.6/site-packages), and adding the path for > lib-dynload to that file (tried absolute and relative paths). I also > tried setting PYTHONPATH to > /usr/lib64/python2.6/lib-dynload:$PYTHONPATH on the Environment tab of > the run config for AllTests. It still fails, and the value of sys.path > that I see in the stack trace does not include the lib-dynload > directory. The dir I pre-pended to PYHTONPATH is not included in the > value of the pythonpath parameter passed in to method Tuple() at > AbstractShell line 748. Any idea how I can add that dir to sys.path > for the tests? > > Here is my stack trace: > > > (None,(ERROR:,Traceback (most recent call last): > File > "/opt/git/Pydev/plugins/org.python.pydev/pysrc/pycompletionserver.py", > line 294, in run > defFile, comps = _pydev_imports_tipper.generate_tip(data, log) > File > "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", > line 132, in generate_tip > f, mod, parent, foundAs = Find(data, log) > File > "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", > line 82, in Find > mod = _imp(name, log) > File > "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", > line 38, in _imp > raise ImportError(s) > ImportError: Unable to import module: math - sys.path: > ['/opt/git/Pydev/plugins/org.python.pydev/tests/pysrc', > '/usr/lib64/python2.6', '/usr/lib64/python2.6/site-packages', > '/usr/lib/python2.6/site-packages/OpenGL'] > > Log:Unable to import module: math - sys.path: > ['/opt/git/Pydev/plugins/org.python.pydev/tests/pysrc', > '/usr/lib64/python2.6', '/usr/lib64/python2.6/site-packages', > '/usr/lib/python2.6/site-packages/OpenGL'] > Traceback (most recent call last): > File > "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", > line 22, in _imp > return __import__(name) > ImportError: No module named math > , )) > > > ------------------------------------------------------------------------------ > 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 |
From: Mark L. <mid...@ve...> - 2016-01-25 19:03:02
|
> > A failure I don't expect: > > In PythonShellTest at line 95, and IndexOutOfBounds exception is > thrown. > The "list" object is empty, apparently because the import for the > "math" > module fails. I believe I have all the python locations and files > specified properly, and if I launch a python shell manually, I can > successfully import the math module. > > > Well, I don't have that failure here, so, it really seems unexpected, > although it's hard to know why without further details -- it probably > means you have some issue communicating with the shell (so, maybe you > could try debugging it there?) In the debugger I see that it fails to import the math module. If I'm reading the stack trace correctly, the directories on sys.path are ['/opt/git/Pydev/plugins/org.python.pydev/tests/pysrc', '/usr/lib64/python2.6', '/usr/lib64/python2.6/site-packages', '/usr/lib/python2.6/site-packages/OpenGL'] When I launch a python 2.6 shell, I can import math successfully, and 'math.__file__' returns /usr/lib64/python2.6/lib-dynload/mathmodule.so So it seems I need to add "/usr/lib64/python2.6/lib-dynload" to sys.path. I tried doing that by creating a file /usr/lib64/python2.6/site-packages/math.pth (the value of PYTHON_SITE_PACKAGES in TestDepedendent.linux.properties is /usr/lib64/python2.6/site-packages), and adding the path for lib-dynload to that file (tried absolute and relative paths). I also tried setting PYTHONPATH to /usr/lib64/python2.6/lib-dynload:$PYTHONPATH on the Environment tab of the run config for AllTests. It still fails, and the value of sys.path that I see in the stack trace does not include the lib-dynload directory. The dir I pre-pended to PYHTONPATH is not included in the value of the pythonpath parameter passed in to method Tuple() at AbstractShell line 748. Any idea how I can add that dir to sys.path for the tests? Here is my stack trace: (None,(ERROR:,Traceback (most recent call last): File "/opt/git/Pydev/plugins/org.python.pydev/pysrc/pycompletionserver.py", line 294, in run defFile, comps = _pydev_imports_tipper.generate_tip(data, log) File "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", line 132, in generate_tip f, mod, parent, foundAs = Find(data, log) File "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", line 82, in Find mod = _imp(name, log) File "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", line 38, in _imp raise ImportError(s) ImportError: Unable to import module: math - sys.path: ['/opt/git/Pydev/plugins/org.python.pydev/tests/pysrc', '/usr/lib64/python2.6', '/usr/lib64/python2.6/site-packages', '/usr/lib/python2.6/site-packages/OpenGL'] Log:Unable to import module: math - sys.path: ['/opt/git/Pydev/plugins/org.python.pydev/tests/pysrc', '/usr/lib64/python2.6', '/usr/lib64/python2.6/site-packages', '/usr/lib/python2.6/site-packages/OpenGL'] Traceback (most recent call last): File "/opt/git/Pydev/plugins/org.python.pydev/pysrc/_pydev_bundle/_pydev_imports_tipper.py", line 22, in _imp return __import__(name) ImportError: No module named math , )) |
From: Fabio Z. <fa...@gm...> - 2016-01-24 18:40:48
|
Hi Mark, On Thu, Jan 21, 2016 at 4:17 PM, Mark Leone <mid...@ve...> wrote: > I'm running the PyDev unit tests to get a baseline before starting some > work on mods to be submitted as a pull request. I believe I have > everything defined correctly in > > org.python.pydev.core/tests/org/python/pydev/core/TestDependent.linux.properties, > with the exception of the IronPython properties. I'm running on CentOS > 6.7, and don't care to install IronPython, which AFAICT requires the > installation and configuration of the Mono framework to get it working > on Linux. > > I'm getting some failures, most of which seem to be expected, but two > are not. Here's what I'm doing and the results. > > 1. Right-click on com.python.pydev.runalltests and select Run As --> > Junit Test > > Failures which I think are expected: > > - IronPython tests fail, since I don't have IronPython installed > > > - There is a failure in org.python.pydev.debug.pyunit.PyUnitViewTest, > which a comment in the code says is to be expected. > - All the tests in com.python.pydev.runalltests2.AllWorkbenchTests fail, > which I assume is expected since I launched the tests as JUnit tests, > not JUnit Plug-In tests. > You can actually just right click "AllTests" > Run As > JUnit test and "AllWorksbenchTests" > Run As > JUnit Plugin Test (you could also run all as junit plugin tests, but as it takes more time to setup, usually I run one and then the other). > > A failure I don't expect: > > In PythonShellTest at line 95, and IndexOutOfBounds exception is thrown. > The "list" object is empty, apparently because the import for the "math" > module fails. I believe I have all the python locations and files > specified properly, and if I launch a python shell manually, I can > successfully import the math module. > Well, I don't have that failure here, so, it really seems unexpected, although it's hard to know why without further details -- it probably means you have some issue communicating with the shell (so, maybe you could try debugging it there?) > > 2. Right-click on com.python.pydev.runalltests and select Run As --> > Junit Plug-In Test. > > A failures which I think is expected: > > - There is an initialization error in > com.python.pydev.runalltests2.AllTests, saying "There are no test cases > to run". I assume this is expected, since I'm running JUnit Plug-In Tests. > Yes, this is expected. > > A failure I don't expect: > > - A ClassCastException is thrown on line 106 of > > AppEngineConfigWizardPageTestWorkbench > > AppEngineConfigWizardPage appEnginePage = (AppEngineConfigWizardPage) > pages[1]; > > The message is > "org.python.pydev.ui.wizards.project.NewProjectExistingSourcesWizardPage > cannot be cast to > > org.python.pydev.customizations.app_engine.wizards.AppEngineConfigWizardPage" > This is expected (it's an error I've been lazy to fix). > > Is this the way I should be running the tests? Are the failures that I > say are expected in fact not a problem? Are the two unexpected failures > indeed a problem, and if so, any ideas what's causing them or how to > resolve them? > Yes, this is the expected way you should be running the tests (although you can just narrow things down as I mentioned earlier) -- as for being a problem, each case is a case -- if you could debug why the first one is failing on your system, that'd be nice... as for the other, I'll take a look at it. Best Regards, Fabio > > -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 > |
From: Fabio Z. <fa...@gm...> - 2016-01-22 11:49:17
|
Release Highlights: ------------------------------- * Debugger * Fixed issue in set next statement (#PyDev 651). * pydevd.settrace was stopping inside the debugger and not in user code (#PyDev 648). * subprocess.Popen could crash when running non python executable (#PyDev 650). * PyUnit view * The last pinned test suite appears as the first entry in the history. * More information is shown on the test run history. * A string representation of the test suite can be saved in the clipboard (last item in the test run history). * Indexing: fixed issue where the indexing and code-analysis could race with each other and one could become corrupt. What is PyDev? --------------------------- PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. Details on PyDev: http://pydev.org Details on its development: http://pydev.blogspot.com What is LiClipse? --------------------------- LiClipse is a PyDev standalone with goodies such as support for Multiple cursors, theming, TextMate bundles and a number of other languages such as Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript, etc. It's also a commercial counterpart which helps supporting the development of PyDev. Details on LiClipse: http://www.liclipse.com/ Cheers, -- Fabio Zadrozny ------------------------------------------------------ Software Developer LiClipse http://www.liclipse.com PyDev - Python Development Environment for Eclipse http://pydev.org http://pydev.blogspot.com PyVmMonitor - Python Profiler http://www.pyvmmonitor.com/ |
From: Mark L. <mid...@ve...> - 2016-01-21 19:52:48
|
Here is the ticket for the hover participant enhancements: https://sw-brainwy.rhcloud.com/tracker/PyDev/653 I developed the ideas discussed in this thread a bit further, so please take a look and provide any additional info, concerns, questions, etc. as comments on the ticket. -Mark On 01/21/2016 04: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 |
From: Mark L. <mid...@ve...> - 2016-01-21 18:17:38
|
I'm running the PyDev unit tests to get a baseline before starting some work on mods to be submitted as a pull request. I believe I have everything defined correctly in org.python.pydev.core/tests/org/python/pydev/core/TestDependent.linux.properties, with the exception of the IronPython properties. I'm running on CentOS 6.7, and don't care to install IronPython, which AFAICT requires the installation and configuration of the Mono framework to get it working on Linux. I'm getting some failures, most of which seem to be expected, but two are not. Here's what I'm doing and the results. 1. Right-click on com.python.pydev.runalltests and select Run As --> Junit Test Failures which I think are expected: - IronPython tests fail, since I don't have IronPython installed - There is a failure in org.python.pydev.debug.pyunit.PyUnitViewTest, which a comment in the code says is to be expected. - All the tests in com.python.pydev.runalltests2.AllWorkbenchTests fail, which I assume is expected since I launched the tests as JUnit tests, not JUnit Plug-In tests. A failure I don't expect: In PythonShellTest at line 95, and IndexOutOfBounds exception is thrown. The "list" object is empty, apparently because the import for the "math" module fails. I believe I have all the python locations and files specified properly, and if I launch a python shell manually, I can successfully import the math module. 2. Right-click on com.python.pydev.runalltests and select Run As --> Junit Plug-In Test. A failures which I think is expected: - There is an initialization error in com.python.pydev.runalltests2.AllTests, saying "There are no test cases to run". I assume this is expected, since I'm running JUnit Plug-In Tests. A failure I don't expect: - A ClassCastException is thrown on line 106 of AppEngineConfigWizardPageTestWorkbench AppEngineConfigWizardPage appEnginePage = (AppEngineConfigWizardPage) pages[1]; The message is "org.python.pydev.ui.wizards.project.NewProjectExistingSourcesWizardPage cannot be cast to org.python.pydev.customizations.app_engine.wizards.AppEngineConfigWizardPage" Is this the way I should be running the tests? Are the failures that I say are expected in fact not a problem? Are the two unexpected failures indeed a problem, and if so, any ideas what's causing them or how to resolve them? -Mark |
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 > > |
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 |
From: Fabio Z. <fa...@es...> - 2016-01-20 11:25:29
|
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 > > > 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 > > |
From: Mark L. <mid...@ve...> - 2016-01-20 05:11:58
|
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 > > > 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 >>>> > ------------------------------------------------------------------------------ > 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 > |
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 >>> |
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 >> |