-
Notifications
You must be signed in to change notification settings - Fork 450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inception (languages within languages within...) #696
Conversation
…the "store as first step, then restore as last step" functionality. We *could* do it that way, but it's harder to integrate. So we'll just add a second "build" method to the builder, which takes the parameters necessary to make a sub-Formatter.
…'d rather not have that...
The problem is, the subrules in a The example is taken straight from our unit tests. If you look at the commit right above this comment, you'll see that the tests went from green to red because I removed the |
@nedtwigg You're experiencing the default behaviour of Groovy, without any Gradle goodness applied to make it behave like you expect. Here's my understanding of the behaviour you're seeing:
The behaviour you've grown to expect from Groovy-with-Gradle is due to the type decoration that Gradle does. Whenever a DSL object is instantiated we transparently add a Closure-accepting method for any method that takes an The simple fix for your issue is to let Gradle instantiate the 'sub-extension`:
To make this work, you'll also need to annotate all of the |
Thanks very much for the pointer @bigdaz, that fixed it! Only minor tweak was that it didn't work until I changed it in two places, the place you pointed out above and also here: spotless/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/SpotlessExtension.java Lines 205 to 226 in c5007aa
|
Oops sorry @nedtwigg, I didn't have the time last weekend to review this - I'm not even sure if I'll have the time next weekend - so if this work needs to be merged in, then please don't wait on me. |
No worries! I'll go ahead and merge it before conflicts start to pileup 👍 |
Shipped in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @nedtwigg, I finally got around to reviewing this!
AFAICT everything looks fine other than my comment below; I don't consider this PR controversial, if anything I quite like the idea of doing different formatting inside certain pieces of code, so this PR has my 👍.
withinBlocks 'javascript block', '<script>', '</script>', { | ||
prettier().config(['parser': 'javascript']) | ||
} | ||
withinBlocksRegex 'single-line @(java-expresion)', '@\\((.*?)\\)', JavaExtension, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not clear on what the regex @\\((.*?)\\)
matches. Should we add a comment or replace it with the example in the Javadoc of FormatExtension.withinBlocks
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In some java-html templating systems (I'm thinking of rocker and play framework 2), you can pass java variables to templates, and render any arbitrary expression with @(someExpression)
, e.g. @(i+1)
. I'm happy for this regex to get changed to anything else, I personally always find them difficult to read. IMO, the intention is just to show "pass a string and it will be used as a regex".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh okay, that makes a lot of sense! Goes to show that I'm not familiar with that class of templating systems. 😛
My opinion is that the example in the doc for FormatExtension.withinBlocks
is easier to understand, since it doesn't rely on an understanding of a certain type of templating system, which I think it makes the intention clearer. But I'm happy to defer to you on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you, but not enough to dig up the javadoc, make the change, and push it. If you want to do it, by all means :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise I'm not fussed enough to want to make the change myself, so let's leave it, it's good enough. :)
Implements #412, based on the work we did in #691. This allows users to apply different formatters to specific subsections of code. For example, the following config:
Turns this:
Into this: