@hartwork I would prefer to apply this first to Core only, extracting as much of the pre-existing style into the formatter configuration as possible. The configuration should focus on enforcing consistency instead of re-styling the existing code.

@hartwork I would prefer to apply this first to Core only

@kaixiong why only fix it in half the code?

, extracting as much of the pre-existing style into the formatter configuration as possible.

We can do that. If you can make a list of "bugs" in the effect, I can see if I can find the knows to turn for it.

The configuration should focus on enforcing consistency instead of re-styling the existing code.

Re-styling was never the key missing, it is a side-effect of the current inconsistency and in that sense a necessity, just the degree of it depends on the config.

@hartwork Plugins that are imported code (actors mostly) come with their own formatting. Some are internally consistent, some are not. What's more, we mostly modify them just to fix bugs so I do not find the need for formatting fixes strong enough to mess up the blame history. Large patches like the one for DancingParticles are not common. I'm okay with applying Core's formatting to the others (input and morph).

I'm okay with applying Core's formatting to the others (input and morph).

@kaixiong is my understanding correct that actors starting from existing multi-file code would then not be discussed regarding whitespace except avoiding unnecessary changes in whitespace (since they are noise in diffs) and that we would auto-format all actor code that started in here just like core — would that be the deal?