New 166 implementation and test suite Adam Nelson (15 Jul 2020 03:10 UTC)
Re: New 166 implementation and test suite Alex Shinn (15 Jul 2020 07:29 UTC)
Re: New 166 implementation and test suite Adam Nelson (15 Jul 2020 15:50 UTC)
Re: New 166 implementation and test suite Adam Nelson (15 Jul 2020 15:52 UTC)
Re: New 166 implementation and test suite Alex Shinn (15 Jul 2020 08:47 UTC)
Re: New 166 implementation and test suite John Cowan (15 Jul 2020 13:45 UTC)
Re: New 166 implementation and test suite Adam Nelson (16 Jul 2020 19:15 UTC)
Re: New 166 implementation and test suite Alex Shinn (20 Jul 2020 08:16 UTC)
Re: New 166 implementation and test suite Adam Nelson (20 Jul 2020 12:53 UTC)
Re: New 166 implementation and test suite Alex Shinn (21 Jul 2020 05:26 UTC)
Re: New 166 implementation and test suite Alex Shinn (20 Jul 2020 08:53 UTC)

Re: New 166 implementation and test suite Adam Nelson 16 Jul 2020 19:14 UTC

> > tabular claims that each column is padded to at least the minimum
> width required by any of its lines, but its actual behavior is that
> lines without an explicit width are also padded to at most the maximum
> width required by any line. The table may be narrower than width,
> whereas columnar is always at least as wide as width unless all widths
> are specified. This behavior should be documented.
>
> I didn't follow this?

In Chibi, if width is 30, tabular may print a table that is narrower
than 30 characters. This differentiates it from columnar, which always
expands to use the full width. But the document doesn't specify this.
The document only says that each column is expanded to *at minimum* the
width of the longest line. It says nothing about the maximum.

Technically, an implementation of tabular that is identical to columnar,
except that columns expand when their contents overflow, would match the
description in the document. But I'm guessing that wasn't your intention.

> > substring-terminal-width is underspecified in several ways. What
> happens when from or to fall in the middle of a fullwidth character?
>
> I don't think this is underspecified.  The docs read:
>
>   Returns the substring of <var>str</var>, starting from the first
>   index exceeding <var>from</var> width, to the first index exceeding
>   <var>to</var> width, exclusive, using the notion of width as defined
>   in <code>string-terminal-width</code>.  Note this naturally groups
>   grapheme clusters together.
>
> Yes, fullwidth characters count as 2 width, but that doesn't change
> these semantics.
> There are unit tests for these cases.

Hmm. You're right, this is more clearly specified than I thought. But
I'm not sure if Chibi's behavior matches this description.

Some examples with fullwidth letters: Based on the description,
(substring-terminal-width "foo" 1 4) should return "o", because the
first index exceeding 1 is 2. But, in Chibi, it returns "fo", even
though the index of "f" (0) precedes from (1). Likewise,
(substring-terminal-width "foo" 2 5) should return "oo", because the
first index exceeding 5, exclusive, is 6. But, in Chibi, it returns "o".