I apologize for the very long delay.

On Fri, Apr 5, 2019 at 10:00 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

(1) For the sake of applicability and coherence, SRFI 166 should be
compatible with SRFI 165. Problems that may be an obstacle to that
should (and can) be addressed in either SRFI 165 or SRFI 166 before
both are finalized.

When a future SRFI standardizes the notion of monads, SRFI 165 should
and would become an implementation of that notion, so SRFI 166 would
automatically gain from it.

I'm sorry but I still fail to see any practical example where an explicit dependence on SRFI 165 is an advantage.

On the other hand, although you've made an extension for predefined environment variables in SRFI 165, it doesn't allow for low-level optimizations as currently implemented, where predefined variables get a fixed memory offset in a state record. SRFI 166 is potentially extremely lightweight, and all around faster than format-string-based libraries, but this is diminished when composition requires a lot of overhead in state updates.

I have yet to benchmark the cost though.

(4) "unicode-terminal-width/jp": I am neither an expert on east Asian
fonts than on unicode" but I am wondering whether characters of
ambiguous width exist only in a Japanese context. Wouldn't
"unicode-terminal-width/cjk" be a better name?

I'm familiar with the Japanese devices and fonts, and you've mentioned libraries which approximate this by checking for Japanese (and not CJK) encodings. I can't find evidence of the problem in Chinese or Korean fonts, but will look around.

(5) The current draft #2 of SRFI 165 adds an immutability flag to
state variables. I think it makes sense for SRFI 166 to adopt this
flag (it has to be added to "make-state-variable"). Currently, it says
under the description of "with!" that: "As the current formatting
state can be captured or reentered with continuations, with! should be
used with caution, and may produce unexpected output in cases."

Added.

(6) The last sentence before the entry for "trimmed/lazy" is superfluous.

Removed.

(7) How are the various "trimmed" procedures supposed to be
implemented in case ANSI escape sequences or Unicode combining
characters are present? (For example, when trimming happens to the
left, the suggested algorithm of taking the longest output does not
yield the correct result.)

In general we can imagine arbitrary compositions that don't work well

together. Trimming in particular is problematic. How should downcase

folding work on a non-trailing Σ (sigma) which is trimmed to become

trailing? This combines two "power" features of the library - suppressing

and rewriting output. We could remove support for such advanced

features altogether, yet they are quite useful.

Should we remove these? I'm considering removing everything but

the base library, on which all else can be built portably anyway.

Assuming we keep them, we should try our best to have sensible rules

so they compose well in most cases, without requiring implementations

to go to unrealistically complex (and slow) efforts.

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> ...))

The alternative is for trimmed* to track ANSI color escapes

independently of the color state variables, which is definitely

too complex.

(8) In trimmed/both, trimming has to be evenly distributed between the
left hand and the right hand side. Do we want to distribute by
character width or by character count?

Width.

(9) The description of "wrapped/char" says:

"As wrapped, but splits simply on individual characters exactly as the
current width is reached on each line. Thus there is nothing to
optimize and this formatter doesn't buffer output."

What is meant by "exactly" when the "string-width" of individual
characters can be larger than 1 so that the exact width cannot be
realized?

Corrected to state width.

(10) SRFI 166 says that under the description of "columnar" that "... and
all but the last column are right-padded."

The reference implementation, however, also pads the right column, at
least according to the following test:
https://github.com/ashinn/chibi-scheme/blob/master/lib/chibi/show-test.sld#L701

In fact, the sample implementation makes a difference between a
char-whitespace? pad-char and a non-char-whitespace? one:
https://github.com/ashinn/chibi-scheme/blob/master/lib/chibi/show/column.scm#L201

What was the intention?

Not to output invisible trailing whitespace.

(11) The state variables "color", "bold", and "underline" should
either be documented so that they can be reasonably used by client
code or be made internal and not exported.

Made internal - since the vars are first-class now there is no need to expose all of them.

Alex