polytypo 1.6.2 → 1.6.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/lib/polytypo/data/VERSION +1 -1
- data/lib/polytypo/data/fixtures/cs.json +1 -1
- data/lib/polytypo/data/fixtures/de-CH.json +1 -1
- data/lib/polytypo/data/fixtures/de-DE.json +1 -1
- data/lib/polytypo/data/fixtures/el.json +1 -1
- data/lib/polytypo/data/fixtures/en-GB.json +1 -1
- data/lib/polytypo/data/fixtures/en-US.json +1 -1
- data/lib/polytypo/data/fixtures/es.json +1 -1
- data/lib/polytypo/data/fixtures/fi.json +1 -1
- data/lib/polytypo/data/fixtures/fr-CA.json +1 -1
- data/lib/polytypo/data/fixtures/fr.json +1 -1
- data/lib/polytypo/data/fixtures/it.json +1 -1
- data/lib/polytypo/data/fixtures/locale-resolution.json +1 -1
- data/lib/polytypo/data/fixtures/nl.json +1 -1
- data/lib/polytypo/data/fixtures/pl.json +1 -1
- data/lib/polytypo/data/fixtures/pt-BR.json +1 -1
- data/lib/polytypo/data/fixtures/pt-PT.json +1 -1
- data/lib/polytypo/data/fixtures/ru.json +1 -1
- data/lib/polytypo/data/fixtures/sv.json +1 -1
- data/lib/polytypo/data/fixtures/tr.json +1 -1
- data/lib/polytypo/data/fixtures/uk.json +1 -1
- data/lib/polytypo/data/locales/registry.json +1 -1
- data/lib/polytypo/data/rules/order.json +1 -1
- data/lib/polytypo/data/rules/quotes.md +27 -9
- data/lib/polytypo/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: f6776ba2390f63971edcd4f09cd84dbb3f1fc3e9678feee541a7f1667694fdbf
|
|
4
|
+
data.tar.gz: 7a6657ca0e43963c3c9f8509a0727a6dc9bbaed2f648b3fd4f295aca1c7bdf03
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 33d644b27e332aef05d2857a9e95598ab05ef5ff56b29a81ba077b5c1d32f0538a8e0d5718a9e5109710227e3559ad67081d3a418910e8cab9a4bc8c242b14c0
|
|
7
|
+
data.tar.gz: e8b828b749cfe12d719590ace28fb24a5f296bc52b14c959c74f24176921eca9c4ba583509198f56a4d9e4f684e3878dcb577add5c554a5c8b593a5680530fe9
|
data/lib/polytypo/data/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
1.6.
|
|
1
|
+
1.6.3
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"spec": "1.6.
|
|
2
|
+
"spec": "1.6.3",
|
|
3
3
|
"$comment": "Locale resolution input. Algorithm is specified in spec/rules/locale-resolution.md and is identical in every runtime — never delegate it to a platform locale-negotiation library. \"spec\" here must track spec/VERSION exactly — it is not itself the global version source; scripts/validate-spec.mjs enforces the match.",
|
|
4
4
|
"locales": [
|
|
5
5
|
"en-US",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"spec": "1.6.
|
|
2
|
+
"spec": "1.6.3",
|
|
3
3
|
"$comment": "Single source of truth for pipeline order. Rules run in ascending `order`. Disabling a rule removes it from the sequence and never reorders the rest. Rule ids are public API (see docs/ARCHITECTURE.md section 5). \"spec\" here must track spec/VERSION exactly — it is not itself the global version source; scripts/validate-spec.mjs enforces the match.",
|
|
4
4
|
"rules": [
|
|
5
5
|
{
|
|
@@ -605,12 +605,18 @@ spec 1.4.0. Measured on this change, `markdown`/`commonmark`, `en-GB`:
|
|
|
605
605
|
words early and the author's own closing mark is left to `apostrophe` as a stray U+2019. §1 of
|
|
606
606
|
that issue is closed by the veto above; §3 is not, and is not going to be.
|
|
607
607
|
|
|
608
|
-
**Why §3 is decided and not merely unfixed.** Two measurements
|
|
608
|
+
**Why §3 is decided and not merely unfixed.** Two measurements — the first on a published
|
|
609
|
+
package, the second on a build patched with the veto it measures, since no release contains it.
|
|
609
610
|
|
|
610
611
|
First, **the U+2019 at the possessive's own position is produced by the pairing, and nothing else
|
|
611
|
-
can produce it.** `apostrophe` cannot
|
|
612
|
-
|
|
613
|
-
|
|
612
|
+
can produce it.** Not because `apostrophe` cannot see past a span boundary — it can, and
|
|
613
|
+
[apostrophe.md](apostrophe.md) §3.3 case 4 says so: the marker is in that rule's `OPENISH`
|
|
614
|
+
(`modes.md` §3.3), which is exactly why `` `x`'s `` reaches case 4 and comes out `` `x`’s ``. It is
|
|
615
|
+
this shape it cannot reach. Case 4 is the only case in the ladder that accepts the marker on the
|
|
616
|
+
left, and it requires `ALNUM` on the **right**; a plural possessive has a space there. Cases 2 and
|
|
617
|
+
2a read `ALNUM` and `CLOSEDELIM` on the left, and cases 3 and 3a read `LETTER`; the marker is in
|
|
618
|
+
none of those three classes (`modes.md` §3.3). So the ladder falls through to case 5 and emits
|
|
619
|
+
nothing. Measured on published 1.6.1,
|
|
614
620
|
`markdown`/`commonmark`, `en-GB`: `` The `xs`' printer works. `` comes back **unchanged** — an
|
|
615
621
|
unmatched span-boundary plural possessive keeps its U+0027. So the cost of this behaviour is a
|
|
616
622
|
consumed *pairing*, and the visible symptom of that appears elsewhere (a stray U+0027 at the real
|
|
@@ -1597,11 +1603,23 @@ reach — the plural possessive, which is byte-identical to a closing mark after
|
|
|
1597
1603
|
1.6.2 corrects §3.2's own measurements of the decision above; no behaviour, fixture or locale
|
|
1598
1604
|
field changes. Two errors, both introduced with the decision record on 2026-09-24 and both
|
|
1599
1605
|
overstating how cheap the decided behaviour is. The first claimed the glyph at the possessive's
|
|
1600
|
-
position was "correct either way" — it is not: `apostrophe`
|
|
1601
|
-
|
|
1602
|
-
published 1.6.1 package. The second counted **7 of 2801 conformance cases** where 2801 is
|
|
1603
|
-
polytypo-js's
|
|
1604
|
-
1366 fixture cases**, and the sixth — this section's own `en-GB` fixture — is now described
|
|
1606
|
+
position was "correct either way" — it is not: `apostrophe` does not reach *this* mark, the plural
|
|
1607
|
+
shape, for the reason the 1.6.3 entry below states, so declining the pairing leaves U+0027 there.
|
|
1608
|
+
Measured on the published 1.6.1 package. The second counted **7 of 2801 conformance cases** where 2801 is the test
|
|
1609
|
+
count of polytypo-js's conformance runner, a figure no other runtime can reproduce; the cost is
|
|
1610
|
+
**6 of the 1366 fixture cases**, and the sixth — this section's own `en-GB` fixture — is now described
|
|
1605
1611
|
rather than left in the count, because the veto moves the pair to the author's mark correctly and
|
|
1606
1612
|
moves the typewriter apostrophe to the possessive at the same time. A conformance count in this
|
|
1607
1613
|
document is a count of fixture cases, never of one runner's tests.
|
|
1614
|
+
|
|
1615
|
+
1.6.3 corrects §3.2's account of *why* the first of those measurements comes out the way it does;
|
|
1616
|
+
again no behaviour, fixture or locale field changes. The 1.6.2 text said `apostrophe` cannot reach
|
|
1617
|
+
a mark whose left neighbour is the inline marker and attributed that to the marker's exclusion
|
|
1618
|
+
from [apostrophe.md](apostrophe.md) §3.1's `CLOSEDELIM`. Both halves were wrong, and the second
|
|
1619
|
+
contradicted `apostrophe.md` §3.3 case 2a's own note in the same vendored tree: the marker is in
|
|
1620
|
+
that rule's `OPENISH`, so `` `x`'s `` does reach case 4 and is curled. What the ladder cannot
|
|
1621
|
+
reach is the *plural* shape, because case 4 — the only case accepting the marker on the left —
|
|
1622
|
+
requires `ALNUM` on the right, and cases 2, 2a, 3 and 3a all read a class the marker is not in.
|
|
1623
|
+
`CLOSEDELIM` is irrelevant to it either way, since case 2a reads `ALNUM` on the right as well. The
|
|
1624
|
+
same entry also called 2801 a vitest total; it is one runner's conformance test count, and the
|
|
1625
|
+
runtime's own total is 4440.
|
data/lib/polytypo/version.rb
CHANGED