On 12/12/2021 15.08, Victor Zverovich wrote:
>> The text also appears to have some extra backslashes.
>
> These are not extra backslashes, these are escaped \ because they are part of string literals. But simple-hexadecimal-digit-sequence should probably be rendered in a different font to make it clear that it's not literal text.

See e.g. [fs.path.modifiers]
for a case where we show output as a quote-delimited string
without going for the string-literal interpretation.

Jens



> - Victor
>
> On Sun, Dec 12, 2021 at 5:12 AM Tom Honermann <tom_at_[hidden] <mailto:tom_at_[hidden]>> wrote:
>
> On 12/11/21 5:47 PM, Jens Maurer wrote:
> > On 11/12/2021 23.00, Victor Zverovich via SG16 wrote:
> >> Hi Tom and other Unicoders,
> >>
> >> Can we review an updated revision of P2286 (https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html> <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html>>) during the upcoming meeting since there is still chance that it can target C++23? This revision addresses the SG16 feedback, particularly around escaping (https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior> <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior>>). I think it's way more important and time sensitive than LWG issues related to fill.
> > 3.2.7 escaping behavior
> >
> > I think this needs to be rephrased using "UCS scalar values".
> > The term "code point" includes surrogate code points, which
> > should not be copied as-is, I think. (They might be lone
> > surrogates, which are better represented using hex escapes.)
> >
> > In the first bullet, when talking about "code points", I'd
> > prefer to see a list using Unicode character names
> > (e.g. "U+0009 CHARACTER TABULATION") rather than character
> > literals (that need escaping interpretation).
> >
> > In the last bullet, the "Otherwise" does not refer to a
> > preceding "if", it seems, so "otherwise" should not be there.
> > Also, "which" -> "that" (restrictive).
> >
> > It seems that the strings shown here are intended to be
> > lexed as string literals, with interpretation of escapes.
> > That is surprising to me.
> > Maybe it would help to refer to [lex] grammar non-terminals,
> > e.g. "hexadecimal-escape-sequence" (italics).
>
> The text also appears to have some extra backslashes.
> "\\u{simple-hexadecimal-digit-sequence}",
> "\\x{simple-hexadecimal-digit-sequence}".
>
> Tom.
>
> >
> > Do we use uppercase or lowercase hex?
> >
> > Jens
>
>