On Thu, Jul 7, 2011 at 3:24 AM, Tomasz Wesołowski
<kosashi@xxxxxxxxx> wrote:
Hello,
How does CDT distinguish between Quick Fixes and Quick Assists?
There are two separate extension points with similar interfaces: IQuickFixProcessor and IQuickAssistProcessor.
This was inherited from JDT. Deviating to far from JDT is a bad idea since it makes porting additional JDT code to CDT harder.
My initial guess was that Quick Fixes are meant to be placed on problems while Quick Assists can be used everywhere. However, I noted that both of them are actually proposed everywhere on Ctrl+1 (both on problems and regular text). Additionally, there is a separate CDT extension point for "marker resolutions", which -in turn- appear only on markers.
In JDT some Quick Assists, for example Rename, can also be used as Quick Fixes. At some point CDT may need it too.
Clearly there is some distinction between QF and QA, but how is it defined and expected to work?
~~~
Another matter besides Ctrl+1 is what is proposed when hovering over a problem. This is a relevant screenshot:
http://imgur.com/4o4hw
BTW- if I hit ctrl+1 in that place, my contributed dummy Quick Assist extension was proposed, but a dummy Quick Fix wasn't. And the hover proposes none of the two.
On Codan problems (or everywhere in correct code), ctrl+1 proposes both Quick Assists and Quick Fixes. Hovers don't propose anything.
The following code is called when determining fixes while hovering over a problem:
org.eclipse.cdt.internal.ui.text.c.hover.ProblemHover.ProblemInfo.getCAnnotationFixes(ICAnnotation)
82 if (!SpellingAnnotation.TYPE.equals(cAnnotation.getType()))
83 return NO_PROPOSALS;
It's likely this this code is a reduced version of JDT code, but the reduction was done when CDT didn't have any correctable problems except spelling ones. I would look at JDT for guidance.
Basically it was hard-coded for the hovers to ignore all proposals besides spelling proposals (if any), and this seems to apply to all instances of ICAnnotation. Strange! Is there any reason for that to stay in the code?
On top of that, commenting out those two lines still won't make the contributed QA or QF to appear in the hover. I'll continue diagnosing that.
~~~
Short summary:
The behaviour of Quick Assists and Quick Fixes seems inconsistent to me at the moment. While debugging and verifying, I'd like to be able to determine if QF and QA are proposed correctly.
For that, I need complete by-design answers to:
- In what situations shall Quick Fixes be proposed?
- In what situations shall Quick Assists be proposed?
Try to stay as close to JDT as possible. A lot of thought and effort went into it.
And to keep things clear, I'm referring to extensions of org.eclipse.cdt.ui.quickFixProcessors and quickAssistProcessors extension points respectively.
Best regards,
-- Tomasz Wesolowski
-sergey
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
