Hi Alex, hi Arthur,

thanks for getting the done. (I know that there is some work left for
me to do with the alternative implementation.)

A few comments:

(1) SRFI 156 is referenced in one heading. You mean SRFI 159.

(2) Many of the procedures in this SRFI are higher-order procedures
and thus have to take the existence of call/cc into account. The nice
thing about the monadic formatting in SRFI 166 is that it is pure (in
the sense of pure function in functional programming), so it just
works with call/cc. I haven't checked the sample implementation for
whether it uses state internally (not the state in the sense of SRFI
165, which is purely pure) in a way such that it would break call/cc
(see call-with-output-generator, for example, which set!s variables).
If the sample implementation does, it should be noted (and amended at
some point in the future) in the implementation section.

(3) We still have no solution for the trimming of Unicode text or text
interspersed with ANSI color codes. John has explained that Unicode
trimming is not trivial (as it may depend on the language and the
script used). Can we add one more functional parameter that does the
actual trimming (and which can be set by the user)? This is what I
initially wrote, but haven't seen a response for yet, I think:

>
> Preserving trailing composing characters is required lest we split
> graphemes, hence the rule in the current draft.  This should be clarified
> for left trimming - we trim the *longest* possible substring from the left.
>
> The result is that given
>
>   (trimmed* <width> (as-<color> <stuff> ...))
>
> the result may or may not truncate the left or right color escapes,
> changing the intended color but not generating any invalid escapes.
> Instead one should always write
>
>   (as-<color> (trimmed* <width> <stuff> ...))

This would exclude some important use cases. Consider color-formatted
Scheme code that is to be displayed in a fixed width field.

>
> The alternative is for trimmed* to track ANSI color escapes
> independently of the color state variables, which is definitely
> too complex.

I would propose to add a new state variable that holds a primitive
trimming procedure that knows how to remove a fixed number of logical
characters from the left and right. Initially, such a trimming
procedure could be bound to a simple version that just removes code
points. The unicode or the color module can then export a more
sophisticated trimming procedure that knows about combining characters
and leaves control sequences as it (e.g. "Hello, <red>World!</red>"
could be trimmed to 5 characters to "Hello<red></red>".

This would be similar to the procedure "unicode-terminal-width", which
is slower than the simple "string-width" procedure, but can be enabled
by the user on a case-by-case basis.

Am Di., 9. Juni 2020 um 05:47 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> Alex Shinn, author of SRFI 166: Monadic Formatting, has asked me to announce "last call" for this SRFI. He believes that it is ready for finalization, but would like to give reviewers one last chance to submit corrections and feedback before we finalize it.
>
> In particular, I appeal to anyone reading this to try the sample implementation, run the tests, and send feedback about your results.
>
> If you're interested in this SRFI, please give your feedback via the SRFI 166 mailing list before 2020-06-16. After that, assuming that no major revisions are required, we will declare it final.
>
> Regards,
>
>
> SRFI Editor