Community
Participate
Working Groups
Currently, there are two kinds of quick assists: - a syntactical one, that can apply textual modifications to the document's text - a semantical one, tha can apply changes to the AST which is then serialized to update the document's text. I propose to allow a third kind of quick assist: One that triggers as template proposal. Implementation Example (within a subclass of DefaultQuickfixProvider): @Fix(FooBarJavaValidator.CLASS_NOT_DEFINED) public void addClassDefinition(final Issue issue, IssueResolutionAcceptor acc) { acc.accept(issue, acc.findTemplate("class"), new TemplateContextSupplier() { @Override public Map<String, String> getVariables(IDocument doc,IQuickAssistInvocationContext cactx) throws Exception { String issueString = doc.get(issue.getOffset(), issue.getLength()); Map<String,String> r = Maps.newHashMap(); r.put("ClassName", issueString); return r; } }); } Besides variables for a template, the user needs to specify: - an offset within the document at which the template should be inserted. - (optional) a prefix and/or a postfix. These are strings that are inserted before/after the the applied template. This is helpful to, for example, insert line-breaks. A name and an icon do not need to be specified explicitly, since they are bound to the template definition. Compared with syntactic/semanitc quick assist, the template quick assist has the advantages, that - existing templates can be reused. - they support for variables that the user can "tab through".
I'ld prefer to provide access to the underlying Eclipse API and allow to pass an ICompletionProposal to the acceptor. TemplateProposal implements that interface but is limited to statically available information.
Michael, please hold your horses until we discussed this proposal. Thanks.
Created attachment 178882 [details] Template Quickfix Integration The attached file provides template quickfix integration as described in my initial post. It works with Xtext 1.0.1 and doesn't need any modifications of Xtext itself. I've created this ticket to find a good way of integrating this directly into Xtext. I initially created this implementation for http://sadl.sourceforge.net/ and the project lead gave permission to contribute it to Xtext.
(In reply to comment #1) > I'ld prefer to provide access to the underlying Eclipse API and allow to pass > an ICompletionProposal to the acceptor. Agreed, that is the kind of flexibility that I would have loved to have when I was implementing this contribution. > TemplateProposal implements that > interface but is limited to statically available information. I guess it's a good idea if the template is available statically. However, one can dynamically set the template's variables, for example.
(In reply to comment #1) > I'ld prefer to provide access to the underlying Eclipse API and allow to pass > an ICompletionProposal to the acceptor. TemplateProposal implements that > interface but is limited to statically available information. proposed solutions 1. reuse CompletionProposalBasedModification (burrito style) since TemplateProposal deprecates ICompletionProposal#apply (called from CompletionProposalBasedModification#apply) its not straightforward to reuse CompletionProposalBasedModification for this. if we still want to allow this we have to make QuickAssistCompletionProposal implement the remaining TemplateProposal interfaces (ICompletionProposalExtension,ICompletionProposalExtension3) and delegate them through to the contained IssueResolution#IModification which introduces unnecessary dependencies for IModification strategies which are not based on ICompletionProposal and worse QuickAssistCompletionProposal has to know about the type of the underlying IModification and more. 2. adapt IssueResolutionAcceptor in order to directly create and add TemplateProposals from within derived QuickfixProvider classes its sufficient to provide some factory methods around some injected TemplateStore and to adapt the IssueResolutionAcceptor to directly accept ICompletionProposals. The XtextQuickAssistProcessor#create has to be modified to simply return those IssueResolutions containing an ICompletionProposal. Solution 2 makes CompletionProposalBasedModification obsolete so that we can deprecate it.
Scheduled for M3 together with bug 321684.
