@facchinm, I also still have a version of this, including extended formatting, lying around that I need to finish up and document. If you're thinking on adding this, I could see if I can find some time soon to share that.

No hurry, take your time, I just posted it here to avoid losing all the tracks due to repo changes and issues being closed on the IDE repo

Is there anything you need from me? (It's been ages and I don't quite remember the code but I guess it won't be that hard)

I mostly need some time to clean things up and document things. Also, I'm not entirely sure that I'm happy with, the way variadic formatting can be customized right now (it does what it should, but it isn't entirely easy to customize things). Perhaps I should dig into that, document how it works now and we can have some discussion about how to improve on that...

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain? I feel the same way, but can't think of a better approach that doesn't break backwards compatibility.
Maybe it'd be better to move formatting entirely out of Print.h (except for very simple things, for the sake of backwards compatibility) to a separate "value formatter" class that does all the formatting work, and leave Print::print for simple multi-argument printing.

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain?

No, that is actually quite fenced off (only needs to be supported as the first two arguments).

What I mean is that in my code I have some ways to provide custom formatters and formatting objects, but that's a bit unwieldy to use (which also impacts the default formatting options, since those are just built-in custom formatters and options).

Maybe it'd be better to move formatting entirely out of Print.h (except for very simple things, for the sake of backwards compatibility) to a separate "value formatter" class that does all the formatting work, and leave Print::print for simple multi-argument printing.

I suspect this would mean that specifying formatting becomes more clunky, or more likely, significantly less efficient (having to construct intermediate objects and formatted values rather than writing them to a stream directly). Not entirely sure, though.

Also, this would cause a disconnect between the currently supported formatting options (base and precision) and any newly added options in terms of syntax.

@cousteaulecommandant, I created#34 for further discussion about formatting, since this is not strictly related to this PR.

We need this one 😍

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain?

No, that is actually quite fenced off (only needs to be supported as the first two arguments).

Why? I think it's perfectly reasonable to expect thatSerial.println("var: 0x", var, 16) prints in hex.

Why? I think it's perfectly reasonable to expect thatSerial.println("var: 0x", var, 16) prints in hex.

Don't worry, that's still supported.print("var: 0x", var, 16) will print"var: 0x" and then callprint with the rest of the arguments (i.e.,print(var, 16)), so we only need to care about the case for two leading numbers.

I was referring to the fact that it is a bit artificial thatprint("foo", "bar") printsfoobar butprint(16, 16) prints10 and not1616. (The feature makes sense and it's easy to document, just tell users not to print two consecutive integers and useprint(16, "", 16) instead if they really want to concatenate integers; my concern was that the implementation was kind of messy.)

All committers have signed the CLA.