Comment author: @Octachron

Would it not be better to merge the intermediaries result with f "foo" "bar" rather than constraining the continuation to return unit?

Comment author: @diml

What would be the use case for such a feature?

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

IIRC it was a halfway house for translating VT100 sequences to Windows API calls which I was doing - if you can effectively separate the calls on %! then you can correctly translate and print "foo\n%!bar\n" (flush "foo"to output, buffer"bar") and "foo\n%!bar\n%!"` (print both lines at once)

It is a rather important property of Format/Printf that the continuation is called once at the end. If you want to call a function on each string, it seems better to make your own formatter. I suggest we close.

@Drup - how so?

Format.formatter_of_out_functions allows you to create a formatter where you provides the function called on each substrings. That's the proper (and intended) way to use printf on semi-exotic channels.

What I was asking was the "important property" you refer to - what prevents there being a version of Printf.ksprintf which behaves as I describe? (but thanks for the pointer - in the wood for the trees, I hadn't considered using formatter_of_out_functions to solve this - one ends up in Format at surprising times, sometimes)

The manual for kfprintf says: passes the formatter to its first argument at the end of printing. I think it is implicit that the continuation is called only when mentioned, but could be wrong. So to my understanding, that means that invoking the continuation at other times is a serious change in semantics. It would certainly break various aspects of my code.

“Obviously, this would have to be done with a new function, as it would be a change of semantics for Printf.ksprintf.”! I was curious that @Drup refers to the entire module...

(@dra27 If you are proposing a new function then maybe you should change the title)

+1 And I would suggest not naming the new function k*printf to avoid the significantly different interpretations of the k prefix.