Does this even have to be publicly exposed? Is the implicit Option[TokenizerOptions]just sugar for tests?

Anyway, I didn't quite get how the options get propagated (and the need for the DynamicVariable to back the default implicit), so I am probably missing a piece.

in your case, since i restored the original behaviour, you don't need to use it. but i will use it in scalafmt, hence i would have to use input.withTokenizerOptions(...) before using the parser.

and yes, I will probably set the global value since scalafmt can occasionally use the parser multiple times (for rewrite rules, mostly), and the global value can be implicitly visible.

does that make sense?

So if I get this right, you'll add withTokenizerOptions() to all Input instance throughout the code in scalafmt, and to avoid passing a custom TokenizerOptions to opt-in grouping whitespaces each time, you'll control the global implicit?

I am still contemplating that Option wrapper.... If the globlal implicit was a TokenizerOptions instead of an Option[Tokenizer], wouldn't the overload you added here (after adding an implicit on the argument) be enough for both cases (providing an explicit option or capturing the default ones that might be custom)?

i originally tried without option but then got bogged down somewhere, don't remember where 🙂 i can try to check again, before we release

OK - anyway, not a blocker for me obviously, just curiosity and willingness to reduce public API if possible

#3919