Lima 0.7.0 — Core 1.2: keys in any script

All three implementations ship 0.7.0 from this tag:

npm	@limaformat/lima@0.7.0
crates.io	lima = "0.7.0"
Go	go get github.com/limaformat/lima/go@v0.7.0

Package versions are independent of the Lima specification version; this release implements Lima Core 1.2 and
Lima References 2.1 (docs/lima-core-1.0-spec.md and docs/lima-references-2.0-spec.md, under their old names
so that published links keep working). Documents that 0.6.0 skipped or rejected for their keys' characters now read,
hence the minor version.

Core 1.2: keys in any script

An unquoted key starts with a letter or number of Unicode 18.0 or _, and after its first character also holds
marks, * and ·. Keys can be written in any language, and gendered, without quotes:

größe: 42
título: Hola
題名: こんにちは
autor:in: Noa
autor*in: Noa
autor·in: Noa

• Unicode 18.0, fixed. The categories are those of the Unicode Character Database 18.0.0, not of whatever Unicode
  the host language knows, so TypeScript, Rust and Go read every key alike. Each carries a generated table; there is
  still no runtime dependency, and ASCII keys are read as fast as before.
• Keys compare as written. Lima normalises no Unicode: an ö typed as one character and one typed as o plus a
  combining mark are two keys. A consumer that wants them equal normalises them itself.
• Invisible characters stay out. Whitespace, control and format characters, the bidirectional controls among
  them, are in no unquoted key.
• A document is Unicode scalar values. TypeScript rejects a lone surrogate and Go invalid UTF-8 with
  INVALID_DOCUMENT and the line, as Rust strings cannot hold them.
• Hints: whitespace other than spaces before a key, a FULLWIDTH COLON (U+FF1A) in place of : , and the
  key-grammar hint for a key such as x y: 2 at every level.

References 2.1

Reference names take the characters of a Core 1.2 key: ${größe}, ${autor*in}, $(personen/zoë.name).

Core 1.2: what each kind of line does, in one table

§7.1 states in one normative table what each kind of line — blank, comment, entry, item, other — does where it
stands, in non-strict and in strict mode, in place of the prose where the Core 1.1 reviews found their issues. No
outcome changes; 124 new corpus cases pin every row, and all three implementations pass them.

Requirements

• @limaformat/lima needs Node.js 22 or later (String.prototype.isWellFormed).

Numbers

Measured by the new scripts/facts.ts and checked in CI: 620 conformance cases in the current target (479 Core, 141
References), 200,000 differential parses per implementation and run, and an npm tarball of 72.3 KB — js-yaml 5.2.3's
is 4.7 times its size.

The full list is in each package's CHANGELOG.md.