Editorial: refer to code points directly by name/number instead of using aliases

[michaelficarra]

Fixes #2930.

[gibson042]

This seems gratuitously divergent from Unicode conventions. Should we instead try to align?

[michaelficarra]

Are you saying we should use small caps? As for the name, I chose to use one of the official aliases when I felt it was more appropriate/descriptive. I can explicitly state that it is the code point name or an alias if you prefer.

[gibson042]

Yes, I think we should use small caps and avoid brackets except for sequences, e.g.

Suggested change

	<li>In the lexical and RegExp grammars, Unicode code points without a conventional printed representation are instead shown in the form "&lt;U+0000 (NULL)>" where `0000` is 4 to 6 hexits representing the code point in hexadecimal notation and `NULL` is the code point name.</li>
	<li>In the lexical and RegExp grammars, Unicode code points without a conventional printed representation are instead shown in the form "U+0000 <small class="code-point-name">NULL</small>" where `0000` is 4 to 6 hexadecimal digits representing the code point and `NULL` is the code point name.</li>

or maybe ecmarkup support

Suggested change

	<li>In the lexical and RegExp grammars, Unicode code points without a conventional printed representation are instead shown in the form "&lt;U+0000 (NULL)>" where `0000` is 4 to 6 hexits representing the code point in hexadecimal notation and `NULL` is the code point name.</li>
	<li>In the lexical and RegExp grammars, Unicode code points without a conventional printed representation are instead shown in the form "<code data-char-name="NULL">U+0000</code>" where `0000` is 4 to 6 hexadecimal digits representing the code point and `NULL` is the code point name.</li>

or even ecmarkdown

Suggested change

	<li>In the lexical and RegExp grammars, Unicode code points without a conventional printed representation are instead shown in the form "&lt;U+0000 (NULL)>" where `0000` is 4 to 6 hexits representing the code point in hexadecimal notation and `NULL` is the code point name.</li>
	<li>In the lexical and RegExp grammars, Unicode code points without a conventional printed representation are instead shown in the form "U+0000 ^^NULL^^" where `0000` is 4 to 6 hexadecimal digits representing the code point and `NULL` is the code point name.</li>

[michaelficarra]

I think it's fine to defer the small-caps names (with possible tooling support) to a follow-up.

[gibson042]

Yeah, I think so. 👍

[gibson042]

#3303 (comment)

The link is good, but I still think an explicit mention of U+0085 (NEXT LINE) and probably also U+FEFF (ZERO WIDTH NO-BREAK SPACE) would be better. As observed in tc39/proposal-regexp-v-flag#37, the classification of these two code points is easy to overlook, and IMO it behooves the spec to highlight that.

Note also that a) https://util.unicode.org/UnicodeJsps is frequently unavailable, and in the recent past was offline for months, and b) even when it is available, there is no obvious indication that 7 of the 8 code points are included in ECMA-262 |LineTerminator| (and thus regular expression pattern \s, which exactly covers the union of |WhiteSpace| and |LineTerminator|) and 1 in the middle is not.

sample output

Basic Latin — C0 controls items: 5
	U+0009	CHARACTER TABULATION; HORIZONTAL TABULATION; HT; TAB
	U+000A	END OF LINE; EOL; LF; LINE FEED; NEW LINE; NL
�	U+000B	LINE TABULATION; VERTICAL TABULATION; VT
	U+000C	FF; FORM FEED
	U+000D	CARRIAGE RETURN; CR
Latin 1 Supplement — C1 controls items: 1
�	U+0085	NEL; NEXT LINE
General Punctuation — Separators items: 2
	U+2028	LINE SEPARATOR
	U+2029	PARAGRAPH SEPARATOR

addressed

[jmdyck]

Everything else LGTM.

[jmdyck]

Note that a |SingleEscapeCharacter| is a single character and does not include the preceding backslash. So it's a mismatch to have |SingleEscapeCharacter| as the column head and then (e.g.) \b below it. (The status quo uses "Escape Sequence" as the column head, which is not a defined term. You'd have to go up to |DoubleStringCharacter| and |SingleStringCharacter| to get a nonterminal that actually includes the backslash.)

The simplest fix would be to delete the backslashes from the data cells (as in Table 61: ControlEscape Code Point Values), although that loses the visual cue that they're 'escape sequences'.

Alternatively, you could insert a backslash into the header cell, but that's a bit dodgy, since:

• `\` |SingleEscapeCharacter| doesn't occur in the grammar, and
• the prose associated with |SingleEscapeCharacter| wouldn't be quite right.

[michaelficarra]

I'll just remove the backslash.

[michaelficarra]

Actually, I think I'll replace it with a code point descriptor.

[jmdyck]

Well, that's valid, but I'm not sure it's an improvement (over just removing the backslashes). The definition of SingleEscapeCharacter is one of ' " \ b f n r t v, so it seems like the natural approach would be to use those characters rather than code point descriptors.

[michaelficarra]

I'm fine with changing to just the single character if the other editors prefer.

addressed