Add support for '# gd-formatter:disable' and '# gd-formatter:enable'.#240
Conversation
refactor the code a little bit
|
Thank you very much for the help! That's much appreciated. The general of swapping the region with a placeholder is the way to go. I went ahead and made some changes on the preprocessing side that actually I probably shouldn't have (As we add more to the program, I'm getting into a mindset of starting to write it a bit better, though writing it well will involve getting rid of topiary, in which case we won't need these ~hacky pre and post processing steps). Practically speaking the changes:
The second point I'm really not attached to, I just picked something used by a popular formatter that's concise to make it a bit more convenient to type. I quickly checked what other formatters used in case there was some standard and it seems to be different and a bit arbitrary, depending on the formatter. If you have any feedback on this, please let me know and otherwise I'll merge the change |
|
Sorry for getting back to this that late been pretty busy weeks for me. However, I am unsure why you changed the second block in the test (437ce1b#diff-c9e22f75481da3de6f68e14c296c1d9f98e88e551780e58d8de706662f22677cL14). |
|
Thanks. I just reintroduced the indents. While working on it, I thought testing for any formatting change, no matter how small, would validate whether a given region is touched by the formatter or not. So having the indents or not didn't make a difference, but it's okay to have them too. And I shouldn't have removed them in the first place. Thank you very much for taking the time to contribute! And no worries about being busy or any delay, I perfectly understand. |
Implements #238.
Please check if the PR fulfills these requirements:
Related issue (if applicable): #238
What kind of change does this PR introduce?
Adds support for special comments:
# gd-formatter:disableand# gd-formatter:enableDoes this PR introduce a breaking change?
I don't think so.