ecmarkup
ecmarkup copied to clipboard
tc39
An HTML superset/Markdown subset source format for ECMAScript and related specifications
The annual published versions of ECMA-262 want to refer to that year's ECMA-402, and conversely. But we are definitely not going to remember to make that change manually, as evidenced...
I would like to start enforcing some basic sanity checks for the spec. Some of them will end up implemented in other projects, but I would like to use this...
In https://github.com/tc39/proposal-pattern-matching, locally `npm run build` is now deterministic. It won't update the date until `spec.emu` is modified. However, PRs that do not update `spec.emu` - and builds on `main`...
If the spec text contains CRLF in a structured header, ecmarkup reports an `expected parameter name` warning for any parameters. Changing all CRLF characters to LF makes the warning go...
instead of [hardcoding a specific list](https://github.com/tc39/ecmarkup/blob/dbd1def88459308e16be9d4febe8388ca7a66a34/src/autolinker.ts#L142).
The boilerplate for an operation that supersedes another of identical name (generally ECMA-402 updating ECMA-262) is something like `This definition supersedes the definition provided in .` (cf. [ECMA-402](https://github.com/tc39/ecma402/blob/26c0562f4d5cf2943df3213d3c6cd9ddee077662/spec/locale-sensitive-functions.html#L113) and [Temporal](https://github.com/tc39/proposal-temporal/blob/1b3d0186dcd202431bd455bf8e76b94e62698c16/spec/intl.html#L1630))....
A parameter name missing leading and/or trailing `_` is accepted, probably erroneously. For example, `_modifiers: a Modifiers,` (as [currently in proposal-regexp-modifiers spec](https://github.com/tc39/proposal-regexp-modifiers/blob/0736a543edf00de8487231688bfcbe89b74f8c54/spec.emu#L572)) renders like "_modifiers (a Modifiers)" with the literal...
https://github.com/tc39/ecmarkup/pull/449 makes the logic for matching productions at least _work_ in the presence of `` and ``, but really you don't want to include ``'d things in the matching logic....
I think highlighting the anchor target would help readability, especially for refs. Specific colors and styles could obviously be tweaked, though. Preview (ref)  Preview (section) 
If you try to consume the `ecmarkup` package via the API, it will fail to type-check because `Clause` is marked `/* @internal */`... https://github.com/tc39/ecmarkup/blob/05d05f71e1bc8cf151da65d34e9105eff3e7d465/src/Clause.ts#L26-L27 but `maybeAddClauseToEffectWorklist` still uses the non-existent...
