Consider the following typical DSL representing a search query:
and {
or {
term 'foo'
term 'bar'
}
not {
term 'baz'
}
}
Assume and(Closure block) method is proposed by the contribution block and the method does not contain required params besides trailing closure.
A much preferred state after autocompletion would be:
For a method with required parameters (e.g. method name: and, namedParams:[score:float]), desired autocompletion would look like this:
Even when Eclipse Content Assist preferences set to "Use closure literals for closure arguments" and "Place trailing closure args after closing parens", the best that could be achieved today is
Desired formatting rules are DSLD-specific, so I propose to add more formatting flags for the "method" tag in the contribution block. We already have noParens which is a good start but it is not sufficient.
We need at least four more options:
- option to suppress "it" as not making sense in this scenario
- option to set caret position next line and insert closing curly bracket one more line below
- option to override preference "Use closure literals for closure arguments"
- option to override preference "Place trailing closure args after closing parens"
I have not investigated how hard this will be to implement, just fishing if this is a sound proposal.
Consider the following typical DSL representing a search query:
Assume
and(Closure block)method is proposed by the contribution block and the method does not contain required params besides trailing closure.A much preferred state after autocompletion would be:
For a method with required parameters (e.g.
method name: and, namedParams:[score:float]), desired autocompletion would look like this:Even when Eclipse Content Assist preferences set to "Use closure literals for closure arguments" and "Place trailing closure args after closing parens", the best that could be achieved today is
Desired formatting rules are DSLD-specific, so I propose to add more formatting flags for the "method" tag in the contribution block. We already have noParens which is a good start but it is not sufficient.
We need at least four more options:
I have not investigated how hard this will be to implement, just fishing if this is a sound proposal.