securemark 0.294.1 → 0.294.3

package/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## 0.294.3
+
+- Refactoring.
+
+## 0.294.2
+
+- Refactoring.
+
 ## 0.294.1
 
 - Refactoring.

package/design.md

@@ -272,37 +272,39 @@ HTMLEntity構文はエンティティ追加時の互換性確保のため不正
 
 ## 備考
 
-### 実行速度
-
-ブラウザの以下の欠陥および低速性により速度低下が生じており今後のブラウザの改善が求められる。
-
-- IntersectionObserverが描画完了前に交差を計算するためすべて同時発火する欠陥
-- CSSカウンター(オーダードリスト)
-
 ### AST(CST)
 
 Securemarkはブロック単位の差分更新によりリアルタイムレンダリングを高速化しているがCSTを生成する場合行の追加削除により以降すべてのノードの位置情報を更新する必要が生じ許容範囲を超える遅延が生じる可能性がある。このためこの最適化を行う必要があるが行位置の更新のみであればこれのみを行う処理経路の追加は容易であろう。Markdownでも行数は数万行以下と想定できることから行数を全ノードに直接記述せず行ノードの行数を参照する実装に変更すれば更新対象を数万以下の行ノードだけに局限できる。これらは数百行以下に規律されるソースコードにおいては生じない問題であり数十万文字を許容しなければならないマークアップ言語に新出の問題であるため新規にCSTの設計および運用を再考する必要がある。
 
 またBlockquote構文を内包テキストまでシンタックスハイライトする場合、構文(>)と内包テキストが垂直に分割されるため構文と1対1で対応する単純なノードではCSTを表現できず構文の断片を表現するノードが必要となり、さらにこれをエディタ上でシンタックスハイライトするためのHTMLに変換する際に各行においてこの断片のCSTを断片のHTMLに正しく変換および表示しなければならずかなり煩雑な作業を要する。
 
-CodeMirrorが素では速いがVimModeでは数万文字程度でも耐え難く非常に遅いので高速な専用エディタの開発が必要。当面は数万文字以上のテキストではTextareaに切り替えることとする。
-
 ### バックトラック
 
-同符号異文脈異構造構文のバックトラックは避けられない。
+バックトラック後にしか到達不能な構文はバックトラックなしに定義不可能。従って他の構文をバックトラック後にしか到達不能にする構文をバックトラックを発生させず追加することも不可能。共通構造を利用してバックトラックを回避する場合も事前に共通構造解析が必要なため複数回解析が必要であり計算量的におよび本質的にバックトラックしているのと変わりない。
 
-- `{ {{A` -> `{{A` -> `{A` -> `A`
 - `[[A` -> `[A` -> `A`
+- `{{A` -> `{A` -> `A`
 
-本質的に括弧として解釈できる符号は予言的構文と見なしてバックトラックを避けられるがそうでない符号は避けられない。
+本質的に括弧として解釈できる記号は開放可能構文と見なして予言的構文として定義することでバックトラックを回避できるがそうでない記号は回避できない。
 
 - `"A` -> `(A`
 - `` `A `` -> `(A`
-- `$100` <> `(100`
+- `$100` >< `(100`
+
+CommonMarkは初手設計ミスったせいで構文一つで最悪計算量32nを叩き出すクソ言語になり拡張性がなく終わってる。
+
+SecuremarkのAnnotation構文に典型的であるように文脈を変更する構文の中にその文脈に依存し変更される他の構文が存在する場合文脈の相違から解析結果を再利用不能(`αAβ | αA'B`)なバックトラックが生じる。またこの結果再帰的バックトラックが生じる可能性があり再帰的バックトラックは一般的にメモ化により解決されるがCommonMarkは最小計算量と実行性能を追及するためメモ化を廃止していることからメモ化により性能を低下させてまで文脈依存構文の問題を解決するつもりはないと思われる(すなわちCommonMarkは機械を至上とし人間に制約を課す低水準の言語であり人間の需要を至上とするSecuremarkとは対極に位置する)。従って再帰的バックトラックなしで解析可能な構文と最小計算量に制約される現在のCommonMarkは基本的に再帰的バックトラックが生じるものである文脈依存構文を追加できないという拡張性の欠陥が存在する(CommonMarkは`~~a~~`のような文脈自由構文は容易に追加できるが文脈依存構文はLink構文で発生している再帰的バックトラックまたはその修正のために激増した計算量を組み合わせ爆発により指数関数的に致命的に悪化させる可能性が高いため基本的に追加できない)。CommonMarkの仕様策定者が構文の拡張に(名称を維持するか否かにかかわらず)不自然なまでに消極的または進展がないのは正当な理由や単なる怠慢からでなく構文追加可否を議論すれば文脈依存構文を基本的に追加できずCommonMarkの構文解析戦略の失敗が明らかになることが避けられないためおよび最小計算量を放棄して現在の高い実行性能を低下させたくないためであり陳腐な自尊心を守るためにこのような拡張性の欠陥を秘匿しCommonMarkとその仕様策定者である自分の評価が下がらないよう画策しているからである。でなければこの拡張性の欠陥を何年も隠さず速やかに公表して助力を求めていなければならず不都合な事実を隠し陳腐な自尊心を守るために全Markdown利用者および開発者を不必要に足止めした罪は重い。
+CommonMarkは小さく単純であるうちだけ破綻せずに正しくいられる象牙の塔であり仕様策定者はこの正しさを失わず正しいままでいたいがために象牙の塔に引きこもり小さな表面的正しさに固執し続けているに過ぎない。しかしCommonMarkは実際にはすでに致命的に破綻しており本来文脈依存言語であるMarkdownを文脈自由言語として解析しようとして失敗したことで指数関数計算量になっており実際のところCommonMarkは最初から最後までずっと壊れている。CommonMarkは可能な限り文脈自由言語として設計することでバックトラックなく最小計算量で解析しようとしているが実際には文脈依存言語であるMarkdownから文脈依存構文を文脈自由構文に変換して再帰的バックトラックを除去することに失敗しているためCommonMarkは最初の数年間は再帰的バックトラックに気づかず最悪計算量が指数関数計算量になっており修正後も依然として最悪計算量が当初の想定の1nから32nへと劇的に悪化している(より正確にはCommonMarkは少なくともCode構文とHTML構文により+2nされるが説明の簡略化のため省略しこれら以外のInline構文のみを比較する)。CommonMarkが最初の数年間他人に指摘され修正されるまで指数関数計算量であった事実(https://github.com/commonmark/cmark/commit/45f4fc9b917c11221aa03e70a41e3046335a235d)はCommonMarkが初歩的な再帰的バックトラックの原理すら理解していないド素人により設計された素人仕事である事実を証明しておりたかが強調構文の解析のためにメモ化を行い(https://github.com/commonmark/commonmark.js/commit/6d7d6cf150dedb53b7f0972b79313df3364ebbed https://github.com/commonmark/commonmark.js/blob/ac8529c9f55da7fdc1186e3f34313cf411de6e71/js/stmd.js )他人にメモ化を使わない正しい実装に修正された事実(https://github.com/commonmark/commonmark.js/commit/8837f199608ac2e321f75653736747b1e692072f)もまたCommonMarkの仕様策定者がその任に堪える能力のないド素人である事実を証明している。スタックを使う代わりにメモ化するド素人の能力を誰が擁護できるのか？ド素人が作った結果初歩的な再帰的バックトラックすら他人に指摘されるまで気づかず修正後も最悪計算量が32nにまで著しく悪化した設計が正しいと言えるのか？不可能である。一貫してド素人により設計開発仕様策定されているCommonMarkは仕様策定が停滞し未だに1nの最小計算量に固執しているがそんなものはCommonMarkの破綻と失敗が露呈するを恐れて隠蔽しまたとっくの昔に破綻してい最小計算量のための設計に未練がましく執着しているだけである。32nという最悪計算量は適切に設計し計算量が抑制された文脈依存言語の最悪計算量より悪く最初から文脈依存言語として適切に設計するほうが自然で破綻がなく拡張性を確保できていた。たった一つの構文だけで最悪計算量が32nも増加するクソ言語に拡張性がないことは明らかである。さらにSecuremarkは再帰的バックトラックを予め対策して設計されているため文脈依存構文数が増えても最悪計算量はたかだか構文数に比例して線形にしか増加しないのに対してCommonMarkは再帰的バックトラックに根本的対策を取れないため文脈依存構文数が増えると最悪計算量が2^mで指数関数的に致命的に爆発する(より正確には通常の文脈依存構文を基準にすれば32\*2^m、リンク構文を基準にすれば32^m)。または計算量を組み合わせ爆発させないために文脈依存構文の入れ子使用を制限する、存在自体が破綻と失敗の宣言に等しい制限が必要になる(リンク構文とイメージ構文を入れ子にできているのはイメージ構文を入れる角括弧部分が文脈自由部分だからであり文脈依存部分である丸括弧部分は入れ子にできていない)。文脈依存構文を強引に文脈自由構文として解析しようとして失敗したために最悪計算量が当初の想定の1nから32nに劇的に悪化し結局文脈依存言語の妥当な最悪計算量より悪い水準に落ちていることおよび文脈依存構文を追加すると最悪計算量が指数関数的に悪化することから文脈自由化に失敗したCommonMarkの破綻と失敗は明らかでありCommonMarkは文脈自由構文に固執せず最初から多少の文脈依存構文を許容するよう設計しなければならなかった。実際には文脈依存言語であるにもかかわらず文脈自由言語の範囲でしか構文解析できなければ構文解析が破綻し構文が増えるほど破綻が拡大することは自明でありすでに破綻済みで失敗済みのCommonMarkに未来などない。文脈依存言語であるMarkdownに対して文脈自由構文解析器として作られたCommonMarkは最初から開発戦略と技術選択を間違え失敗しており最初から破綻していた。CommonMarkが文脈依存言語を文脈自由言語として最小計算量で解析するために使用した手法は邪道の小手先の技術に過ぎずCommonMarkは邪道を選んだ挙句失敗に終わったのである。文脈依存言語を文脈依存言語のまま解析する正道を選んだSecuremarkが正着し文脈依存言語を文脈自由言語に歪める邪道を選んだCommonMarkが失着に終わったのは当然の帰結であり最初の解析戦略時選択の時点で決まっていたことである。文脈依存言語であるMarkdownを文脈自由言語として解析しようとした結果行き詰ったCommonMarkとその閉塞に技術的合理性はなくCommonMarkは最初からの失敗していた過去の遺物であり廃棄すべき負債である。CommonMarkに動きがないのはすでに破綻しており死んでいることに気付かれないように死んでいるからに過ぎない。このようにCommonMarkは完全に破綻し失敗に終わっているためCommonMarkの拡張や発展を期待しても無駄であり既存の文脈依存構文の最悪計算量を健全化し新たに文脈依存構文を追加可能な拡張性の高いMarkdown仕様は新しく作り直さなければ作れない。しかしCommonMarkの仕様策定者は独自の新しい仕様においても依然としてMarkdownを文脈自由化して文脈自由言語として設計しているため文脈依存構文を追加すると指数関数計算量になり救いようがない。しかもその構文と仕様は機械可読性を至上としているため非常に醜く人間が書くことも読むことも困難で人間に対する実用性が欠如している。
+Securemarkはスーパークラス構文が解析に失敗した入力をサブクラス構文で解析しないことにより再帰的バックトラックを回避する(解析中の構文自身はスーパークラスとサブクラスの両方に含まれるものとする)。スーパークラス構文A(`αAβ`)の解析が失敗すればサブクラス構文B(`α'Aβ'`)の解析も失敗することは自明であり試みるまでもなく解析を省略できる。これは二つの構文の文法が生成する各言語空間がスーパーセットとサブセットの関係にあるならスーパーセットの言語空間の外にある文字列はサブセットの言語空間の内に入る余地がないことからも自明である(この解析法は事前解析によっても可能だが文脈内外のオートリンクURLの括弧解析などを高速に行うこともバックトラックなしで解析することも困難であり本解析に近い解析コストを要するためMarkdownをこの事前解析により高速化することは難しい)。メモ化は解析結果を再利用することで結果的に副次的効果としてバックトラックを回避しているものでありメモ化はバックトラックを回避するだけなら過剰であり不要である(メモ化はバックトラックがなければ使用されないためバックトラックの少ないほとんどの入力に対してはほとんど使用されず無駄であり空間計算量を不必要に常時数倍以上増加させることから構文解析において必須にも標準にもできない。バックトラック回避のためにメモ化するとバックトラックなしで解析可能な場合も常に不必要に空間計算量が増加し平均計算量が有意に悪化することがメモ化の最大の欠点である(この問題は解析失敗時のみメモ化すれば解消可能のはずだが基本的にはこうなる)。特に文脈自由構文解析器におけるメモ化の使用は完全に無駄でありバグである。バックトラックが発生しないか他の方法で解決されるならば使用されず破棄されるメモ化は無駄である。複数の文脈で解析結果が同一である文脈独立性のある構文ならメモ化した解析結果を異なる文脈で再利用でき有用だがそのような構文は基本的に少数であるため効果が限定的であり最悪計算量は改善されない)。この解析法により、CommonMarkならば最悪計算量32n\*2^5=1024nを下らない拡張Markdown言語をSecuremarkはメモ化なしで5nの最悪時間計算量で解析している。すなわち言語差を考慮せず直接比較してさえ単純なCommonMarkの最悪計算量32nに対して複雑なSecuremarkは5nに過ぎずSecuremarkはCommonMarkより最悪計算量が非常に小さい。またSecuremarkはメモ化を行っていないため空間計算量も小さい。時間計算量と空間計算量を合わせてO(n, n)と表記すると文脈依存言語の通常の最悪計算量はO(n^2, n)、メモ化により効率化できた場合もO(nm, nm)(S(m)>=m byte)(解析結果の位置や構文木等を記録するため空間使用量S(m)>はm byte以上となり数値一つやポインタ一つだけでも8byteを消費する)に過ぎないがSecuremarkのマーキング法はO(nm, nm)(S(m)=m bit)(解析の失敗フラグしか記録しないためS(m)=m bit。また包含文字列を含め全体でn byteの構文1つに対して解析結果の構文木を保持するメモ化は少なくとも構文木のサイズn byteを消費するがマーキング法のメモリ消費量は構文全体のサイズにかかわらず1bit固定である。よって100KBの構文1つに対してメモ化は100KB以上消費するがこの場合もマーキング法は1bitしか消費しない。なお成功フラグによる解析は成功フラグがないのが失敗したからか未到達だからかを判別するための情報と処理が追加で必要になり処理が複雑化しさらに成功フラグは解析のほとんどを占める成功した解析に対してメモリ消費と追加処理が発生し解析効率が全体として悪化するが失敗フラグは少数の失敗した解析でしか解析効率が悪化しないため失敗フラグを記録するほうが全体および平均として解析効率が高く優れている)と極めて効率的であり最も優れている。以上のようにSecuremarkの構文解析アルゴリズムの優位性は理論と実践いずれにおいても圧倒的である。現在のSecuremarkは開発効率と安全性優先の実装により実行性能が大きく低下しているがクライアントで個別のユーザーの操作に応じるには十分高速であるためクライアントで解析するなら解析の効率または速度が実用上問題となることはなく仕様が固まり実行効率優先の高速な実装に移れば他の環境での懸念もないだろう。またSecuremarkの再帰数制限はパーサーコンビネーターの使用による実装依存の制限であるため再帰が生じないよう書き換えれば再帰数制限もない。SecuremarkをCommonMarkのような再帰数制限のない実装に変換することは設計上何の支障もないがCommonMarkをSecuremarkのような正常な文脈依存言語解析器に変更することは現在の異常な解析規則の破壊的変更による修正なしに不可能である。具体的には二重リンク`[[]()]()`を解析するときCommonMarkはバックトラックと計算量を最小化すべく文脈自由構文解析器として設計されているためリンク構文内をリンク構文が定義されていない異なる文脈として解析せず外側のリンク構文の解析を破棄して内側のみリンク構文として解析するがSecuremarkは文脈依存構文解析器とし設計されているためリンク構文内にリンク構文が定義されておらず外側のみリンクとして解析し他のMarkdown構文解析器もこのように解析しなければならない(ここでCommonMarkはリンク構文`[]()`のバックトラック除去ひいては文脈自由化に角括弧`[]`に対しては成功したが丸括弧`()`に対しては失敗したことで最悪計算量が指数関数計算量ないし32nに悪化した。リンク構文を本来通り文脈依存構文として解析すればリンク構文の最悪計算量が2nとなり角括弧部分に限っては1nから2nに悪化するが丸括弧部分は32nから2nに著しく改善する。ここがCommonMarkの根本的な欠陥と失敗が最も明瞭に表出している部分である)。この問題はイメージ構文においてさらに顕著でありリンク構文と同じ問題が正当な表現`![![]()]()`で発生しさらにHTMLのaltはプレーンテキストとして表示されるためMarkdownのaltもプレーンテキストとしてそのまま表示されなければならないにもかかわらず文脈を一致させ再帰的バックトラックを防ぐためにMarkdown文字列として解析しaltに`*a*`と書かれたものを`a`に変換して表示する。無論新しい文脈依存構文を追加する場合も同じ制約が永遠についてまわり構文内文字列をMarkdownとして解析する文脈依存構文においてこの制約を破ると最悪計算量が2^m、より正確には32\*2^mないし32^mで指数関数的に増加する。すなわちCommonMarkは文脈依存構文を追加すると最悪計算量が32\*2^mないし32^mで指数関数的に悪化するという拡張性の致命的欠陥が存在する。こんな最悪計算量が32^mで組み合わせ爆発する欠陥言語を拡張できるわけがないことはもはや明白である。また大多数のプログラミング言語を見ても明らかなように文脈依存言語は構文内で使用可能な構文を定義しその他の構文は使用できず例外処理するのが通常でありCommonMarkのように本来使用不能な構文を外側の構文を無効化して使用可能に変える異常な言語はほとんどの人間はCommonMark以外に見たことがないだろう。ほぼすべての人間において他のすべての言語が同じ一貫した規則を持ち同じ規則で統一的に使用できるのに対してCommonMarkだけが他と異なる異常な挙動をして使用者に認知的負荷をかけるのである。破壊的変更を避けるため旧構文だけ従来通り文脈自由構文として解析し新構文を文脈依存構文として解析すればキメラ的な非常に不自然かつ歪で一貫性のない解析規則によりCommonMarkという一つの言語の中だけでもユーザーを混乱させるものとなり旧構文で使用した苦肉の策を不必要に新構文でも使用して一貫させれば文脈依存言語なのに文脈自由言語の苦肉の策の解析規則で解析されるこれもまたキメラ的な非常に不自然かつ理論的に設計ミスが明白で実用的にも認知的負荷の高い言語となる。正しく設計された言語と解析器にはありえないこのような解析規則の根本的不整合はその不整合の存在そのものが言語と解析器が誤った設計による失敗作であることを証明しており不整合が存在する限りその不整合により自らが失敗作であることを宣言し続けることになる。CommonMarkとはそういう失敗した言語と解析器なのである。このようにCommonMarkは新構文だけまたは解析器だけ文脈依存に変更しても理論的齟齬が解析結果と使用感の不自然さと違和感に明白に表れるためCommonMarkが失敗した言語である事実は到底隠し切れるものではない。Markdownはもはや負債以外の何物でもないCommonMarkの異常な解析規則を捨てて素直な文脈依存構文言語として新しい仕様を作り直すのが賢明である。
+文脈依存言語をバックトラックなしで解析可能な方法は2つある。一つは解釈を予言的に決定する方法、もう一つは予備的または中間的その他事前の解析結果に対する解釈を事後に決定する方法である。前者は構文を峻別するための制約が強く後者は共通構造の適切な設計が必要でありいずれもバックトラックを防ぐために未終端の構文も受理する必要がある。しかし予言的解析は類似の異文脈構文へのバックトラックが不可能になるため共通構造についての事前解析結果のような追加情報を利用できるのでなければ類似の異文脈構文の定義が不可能になる。また共通構造をバックトラックなしで解析するにはそのための言語設計が必要であることに変わりなく任意の文字列を使用可能である必要があるURL、コード、数式などに含まれる任意の文字列が他の構文と文脈で解釈される際に共通構造を破壊するためこれらを絶対的に分離する基本構造を共通構造に定義しなければ構造的共通化は不可能であり分離構造は終端不要な開放可能構文としての予言的構文でなければバックトラックが不可避となる。共通構造の事前解析は一見すると最悪計算量を2nに削減できるように見えるが実際には共通構造をバックトラックなしで解析することが元の言語より容易にはなっても依然として難しくバックトラックなしで解析できたとしてもすべての解析ひいては平均計算量が+1nされるため平均的にはむしろ好ましくない方法であり仮に最悪計算量32nを事前解析により2nに抑えられたとしても平均計算量が1nならば平均計算量が2nに倍加し実行性能が半減および実行コストが倍加するため明らかに事前解析を行うべきでない。メモ化が空間計算量を代償に悪化させる最悪時間計算量線形化手法であるのに対して事前解析は平均時間計算量を代償に悪化させる最悪時間計算量線形化手法でありマーキング法は何も代償に悪化させない最悪時間計算量線形化手法である。なおマーキング法を使用するSecuremarkは本来の構文解析と共通構造解析を統合し同時解析することで計算量の増加なく共通構造解析を行い共通構造を利用して最悪時間計算量を指数関数計算量から5nへ削減している。
+
+### 実行性能
+
+構文数と使用記号数が大きく異なるため単純な比較はできないがSecuremarkはパーサーコンビネータの多用によるオーバーヘッドが大きく、パーサーを展開しオーバーヘッドを削減すればCommonMarkとの性能差は数倍以下に収まると考えられる。CommonMarkの問題の解決を試みたdjotとの性能差はすでに2倍程度であり本質的な問題は存在しない。
+
+そのほかブラウザの以下の欠陥および低速性により速度低下が生じており今後のブラウザの改善が求められる。
 
-SecuremarkのAnnotation構文に典型的であるように文脈を変更する構文の中にその文脈に依存し変更される他の構文が存在する場合文脈の相違から解析結果を再利用不能(`αAβ | αA'B`)なバックトラックが生じる。またこの結果再帰的バックトラックが生じる可能性があり再帰的バックトラックは一般的にメモ化により解決されるがCommonMarkは最小計算量と実行性能を追及するためメモ化を廃止していることからメモ化により性能を低下させてまで文脈依存構文の問題を解決するつもりはないと思われる(すなわちCommonMarkは機械を至上とし人間に制約を課す低水準の言語であり人間の需要を至上とするSecuremarkとは対極に位置する)。従って現在の再帰的バックトラックなしで解析可能な構文と最小計算量に制約されるCommonMarkにはこれ以上再帰的バックトラックが生じる可能性を増加させて文脈依存構文を追加できないという拡張性の欠陥が存在する(CommonMarkは`~~a~~`のような文脈自由構文は容易に追加できるがこうしたマージンを失えばもはや後はなく文脈依存構文を追加できないという事実に直面する)。CommonMarkの仕様策定者が構文の拡張に(名称を維持するか否かにかかわらず)不自然なまでに消極的または進展がないのは正当な理由や怠慢からでなく文脈依存構文を追加するにつれて構文解析戦略の失敗が明白になっていくためおよび最小計算量を放棄して現在の高い実行性能を低下させたくないためであり陳腐な自尊心を守るためにこのような拡張性の欠陥を秘匿しCommonMarkとその仕様策定者である自分の評価が下がらないよう画策しているからである。でなければこの拡張性の欠陥を何年も隠さず速やかに公表して助力を求めていなければならず不都合な事実を隠し陳腐な自尊心を守るために全Markdown利用者および開発者を不必要に足止めした罪は重い。
-CommonMarkは小さく単純であるがゆえに正しくいられる象牙の塔であり仕様策定者はこの正しさを失わず正しいままでいたいがために象牙の塔に引きこもり小さな表面的完全性に固執し続けているに過ぎない。しかしCommonMarkは実際にはまったく完全ではなく本来文脈依存言語であるMarkdownを文脈自由言語として解析しているため破綻している部分があり実際のところCommonMarkは最初から最後までずっと壊れている。CommonMarkはバックトラックなく最小計算量で解析するために文脈自由言語として設計されているが実際には文脈依存言語であるMarkdownから文脈依存構文を文脈自由構文に変換して除去することに失敗しているためCommonMarkは最初の数年間は再帰的バックトラックに気づかず最悪計算量が指数関数計算量になっており修正後は最悪計算量が当初の想定の2nから32nへと劇的に悪化している(より正確にはCommonMarkはCode構文とHTML構文により+2nされるが説明の簡略化のため省略する)。CommonMarkが最初の数年間他人に指摘され修正されるまで指数関数計算量であった事実(https://github.com/commonmark/cmark/commit/45f4fc9b917c11221aa03e70a41e3046335a235d)はCommonMarkが初歩的な再帰的バックトラックの原理すら理解していないド素人により設計された素人仕事である事実を証明しておりたかが強調構文の解析のためにメモ化を行い(https://github.com/commonmark/commonmark.js/commit/6d7d6cf150dedb53b7f0972b79313df3364ebbed https://github.com/commonmark/commonmark.js/blob/ac8529c9f55da7fdc1186e3f34313cf411de6e71/js/stmd.js )他人にメモ化を使わない正しい実装に修正された事実(https://github.com/commonmark/commonmark.js/commit/8837f199608ac2e321f75653736747b1e692072f)もまたCommonMarkの仕様策定者がその任に堪える能力のないド素人である事実を証明している。スタックを使う代わりにメモ化するド素人の能力を誰が擁護できるのか？ド素人が作った結果初歩的な再帰的バックトラックすら他人に指摘されるまで気づかず最悪計算量が32nにまで著しく悪化した設計が正しいと言えるのか？不可能である。一貫してド素人により設計開発仕様策定されているCommonMarkは未だにバックトラックを忌避し2nの最小計算量に固執しているがそんなものはとっくの昔に破綻してるのを未練がましく執着しているだけである。最悪計算量が32nにまで悪化するのであれば計算量が少ないよう適切に設計された文脈依存言語と大差なく最初から文脈依存言語として適切に設計するほうが自然で破綻がなく拡張性を確保できていた。。さらにSecuremarkは再帰的バックトラックを対策しているため文脈依存構文数が増えても最悪計算量は1+mで定数的にしか増加しない(新しい構文の新しい文脈も内部の括弧類のような基本構造は共通であるため一度解析すればあとは既存の解析情報を利用してバックトラックなしで1回で解析できる)がCommonMarkは再帰的バックトラックを対策していないため文脈依存構文数が増えると最悪計算量が2^mで指数関数的に致命的に激増する(より正確には通常の文脈依存構文を基準にすれば32\*2^m、リンク構文を基準にすれば32^m)。または計算量が組み合わせ爆発しないよう文脈依存構文の入れ子を制限する、存在自体が欠陥と失敗の宣言に等しい制限が必要になる(リンク構文とイメージ構文を入れ子にできるのはaltを不適切に外部と同じ文脈のMarkdownとして解析することで文脈自由化しているからであり本来文脈依存構文は異なる文脈を持つためこのようなことはできずイメージ構文もこの本来できない文脈自由化を行ったためにCommomMarkではaltがプレーンテキストでなくMarkdownとして不適切に解析されている)。文脈依存構文を強引に文脈自由構文として解析したために最悪計算量が当初の想定の2nから32nに劇的に悪化し結局文脈依存言語の妥当な最悪計算量の水準に落ちていることおよび文脈依存構文を追加すると最悪計算量が指数関数的に悪化することから文脈自由言語として設計されたCommonMarkの破綻と失敗は明らかでありCommonMarkは文脈自由構文に固執せず最初から多少の文脈依存構文を許容するよう設計しなければならなかった。実際には文脈依存言語であるにもかかわらず文脈自由言語としてしか構文解析できなければ構文解析が破綻し構文が増えるほど破綻が拡大することは自明でありすでに破綻済みで失敗済みのCommonMarkに未来などない。文脈依存言語であるMarkdownに対して文脈自由構文解析器として作られたCommonMarkは最初から技術選択を間違え失敗しており最初から破綻していた。CommonMarkが文脈依存言語を文脈自由言語として最小計算量で解析するために使用した手法は邪道の小手先の技術に過ぎずCommonMarkは邪道を選んだ挙句失敗に終わったのである。文脈依存言語を文脈依存言語のまま解析する正道を選んだSecuremarkが正着し文脈自由言語に歪める邪道を選んだCommonMarkが失着に終わったのは当然の帰結であり最初の言語種別選択の時点で決まっていたことである。文脈依存言語であるMarkdownを文脈自由言語として解析しようとして行き詰ったCommonMarkとその閉塞に技術的合理性はなくCommonMarkは最初からの失敗していた過去の遺物であり廃棄すべき負債である。CommonMarkに動きがないのはすでに破綻しており死んでいることに気付かれないように死んでいるからに過ぎない。このようにCommonMarkは完全に破綻し失敗に終わっているためCommonMarkの拡張や発展を期待しても無駄であり既存の文脈依存構文による破綻がなく新たに文脈依存構文を追加可能な拡張性の高いMarkdown仕様は新しく作り直さなければ作れない。しかしCommonMarkの仕様策定者は独自の新しい仕様においてもMarkdownをバックトラックを排除した文脈自由言語として設計しているため救いようがない。しかもその構文と仕様は機械可読性を至上としているため非常に醜く人間が書くことも読むことも困難で実用性の欠如したものである。
-Securemarkはスーパークラス構文が解析に失敗した入力をサブクラス構文で解析しないことにより再帰的バックトラックを回避する(解析中の構文自身はスーパークラスとサブクラスの両方に含まれるものとする)。スーパークラス構文A(`αAβ`)の解析が失敗すればサブクラス構文B(`α'A'β'`)の解析も失敗することは自明であり試みるまでもなく解析を省略できる。これは二つの構文の文法が生成する各言語空間がスーパーセットとサブセットの関係にあるならスーパーセットの言語空間の外にある文字列はサブセットの言語空間の内に入る余地がないことからも自明である(この解析法は事前処理によっても可能だが文脈内外のオートリンクURLの括弧解析などを高速に行うことは困難であるためMarkdownをこの事前処理により高速化することは難しい)。メモ化は解析結果を再利用することで結果的に副次的効果としてバックトラックを回避しているのでありメモ化はバックトラックを回避するだけなら過剰機能であり不要である(メモ化はバックトラックがなければ使用されないためバックトラックの少ないほとんどの入力に対してはほとんど使用されず無駄であり空間計算量を常に不必要に数倍以上に増加させてまで行う利益は少ないことから構文解析において必須でも標準でもない。バックトラック回避のためにメモ化するとバックトラックなしで解析可能な場合も常に不必要に空間計算量が増加することがメモ化の最大の欠点である(この問題は解析失敗時のみメモ化すれば解消可能のはずだが基本的にはこうなる)。特に文脈自由構文解析器におけるメモ化の使用は完全に無駄でありバグである。バックトラックが発生しないか他の方法で解決されるならば最終的に使用されないメモ化は無駄であり複数の文脈で解析結果が同一である文脈独立性のある構文ならメモ化した解析結果を異なる文脈で再利用でき有用だがそのような構文は基本的に少数であるため効果が限定的であり最悪計算量は改善されない)。この独自の解析法により、CommonMarkならば最悪計算量32n\*2^2+4n=132nを下らない拡張Markdown言語をSecuremarkはメモ化なしで5nの最悪時間計算量で解析している。すなわち直接比較してもCommonMarkの最悪計算量32nに対してSecuremarkは5nでありSecuremarkはCommonMarkより最悪計算量が非常に小さい。またSecuremarkはメモ化を行っていないため実装依存の非効率性を除けば空間計算量も小さい。時間計算量と空間計算量を合わせてO(n, n)と表記すると文脈依存言語の通常の最悪計算量はO(n^2, n)、メモ化により効率化できた場合もO(nm, nm)(S(m)>=m byte)(解析結果の構文木等を記録するため空間使用量S(m)>=m byte)に過ぎないがSecuremarkのマーキング法はO(nm, nm)(S(m)=m bit)(解析の失敗フラグしか記録しないためS(m)=m bit。また包含文字列を含め全体でn byteの構文1つに対してメモ化は少なくともn byteを消費するがマーキング法のメモリ消費量は構文全体のサイズにかかわらず1bit固定である。よって100KBの構文1つに対してメモ化は100KB以上消費するがこの場合もマーキング法は1bitしか消費しない。なお成功フラグによる解析は成功フラグがないのが失敗したからか未到達だからかを判別するための情報と処理が追加で必要になり処理が複雑化しさらに成功フラグは解析のほとんどを占める成功した解析に対してメモリ消費と追加処理が発生し解析効率が全体として悪化するが失敗フラグは少数の失敗した解析でしか解析効率が悪化しないため失敗フラグを記録するほうが全体として解析効率が高く優れている)と極めて効率的であり最も優れている。以上のようにSecuremarkの構文解析アルゴリズムの優位性は理論と実践いずれにおいても革新的かつ圧倒的である。現在のSecuremarkは開発効率と安全性優先の実装により実行性能が大きく低下しているが一定時間内で解析不能な入力の影響を解析時間と解析範囲の制限により局限しているため、最悪計算量で低速に動作させる入力に対してはこの実装をサーバーで使用し多数のユーザーのリクエストに応じるには低速で脆弱性となる可能性があるがクライアントで個別のユーザーの操作に応じるには十分高速であるためクライアントで解析する限り解析の効率または速度が実用上問題となることはなく仕様が固まり実行効率優先の高速な実装に移れば速度面の懸念もないだろう。またSecuremarkの再帰数制限はパーサーコンビネーターの使用による実装依存の制限であるため再帰が生じないよう書き換えれば再帰数制限もない。SecuremarkをCommonMarkのような再帰数制限のない実装に変換することは設計上何の支障もないがCommonMarkをSecuremarkのような正常な文脈依存言語解析器に変更することは解析規則の破壊的変更なしに不可能である。具体的には二重リンク`[[]()]()`を解析するときCommonMarkはバックトラックと計算量を最小化すべく文脈自由構文解析器として設計されているためリンク構文内をリンク構文が定義されていない異なる文脈として解析せず外側のリンク構文の解析を破棄して内側のみリンク構文として解析するがSecuremarkは文脈依存構文解析器とし設計されているためリンク構文内にリンク構文が定義されておらず外側のみリンクとして解析する(ここでCommonMarkはリンク構文`[]()`のバックトラック除去ひいては文脈自由化に角括弧`[]`に対しては成功したが丸括弧`()`に対しては失敗したことで最悪計算量が指数関数計算量ないし32nに悪化した。リンク構文を本来通り文脈依存構文として解析すればリンク構文の最悪計算量が2nとなり角括弧部分に限っては1nから2nに悪化するが丸括弧部分は32nから2nに著しく改善する。ここがCommonMarkの根本的な欠陥と失敗が最も明瞭に表出している部分である)。この問題はイメージ構文においてさらに顕著でありリンク構文と同じ問題が正当な表現`![![]()]()`で発生しさらにHTMLのaltはプレーンテキストとして表示されるためMarkdownのaltもプレーンテキストとしてそのまま表示されなければならないにもかかわらず文脈を一致させ再帰的バックトラックを防ぐためにMarkdown文字列として解析されaltに`*a*`と書かれたものを`a`に変換して表示する。無論新しい文脈依存構文を追加する場合も同じ制約が永遠についてまわり構文内文字列をMarkdownとして解析する文脈依存構文においてこの制約を破ると最悪計算量が2^m、より正確には32\*2^mないし32^mで指数関数的に増加する。すなわちCommonMarkは文脈依存構文を追加すると最悪計算量が32\*2^mないし32^mで指数関数的に悪化するという拡張性の致命的欠陥が存在する。こんな最悪計算量が32^mで組み合わせ爆発する欠陥言語を拡張できるわけがないことはもはや明白である。また多くのプログラミング言語を見ても明らかなように文脈依存言語は構文内で使用可能な構文を定義しその他の構文は構文内で使用できず例外処理するのが通常でありCommonMarkのように本来使用不能な構文を外側の構文を無効化して使用可能に変える異常な言語はほとんどの人間はCommonMark以外に見たことがないだろう。ほぼすべての人間において他のすべての言語が同じ一貫した規則を持ち同じ規則で統一的に使用できるのに対してCommonMarkだけが他と異なる異常な挙動をして認知的負荷をかけるのである。破壊的変更を避けるため旧構文だけ従来通り文脈自由構文として解析し新構文を文脈依存構文として解析すればキメラ的な非常に不自然かつ歪で一貫性のない解析規則によりCommonMarkという一つの言語の中だけでもユーザーを混乱させるものとなり旧構文で使用した苦肉の策を不必要に新構文でも使用して一貫させれば文脈依存言語なのに文脈自由言語の苦肉の策で解析されるこれもまたキメラ的な非常に不自然で理論的に設計ミスが明白で実用的にも認知的負荷の高い言語となる。そして構文エラーであることが明らかな二重リンクを意図的に入力することはほぼないためCommonMarkの異常な挙動はこれまであまり人目に付かなかったがMarkdownに文脈依存構文を追加して明らかでない構文エラーが頻発すると他の言語と逆に外側の構文を無効化していくCommonMarkの異常な挙動を頻繁に目撃し認知的負荷をかけられることになる。このようにCommonMarkは内部設計だけ文脈依存構文解析器に変更しても理論的齟齬が解析結果と使用感に明白に表れるためCommonMarkが失敗した言語である事実は到底隠し切れるものではない。Markdownはもはや負債以外の何物でもないCommonMarkの異常な解析規則を捨てて素直な文脈依存構文言語として新しい仕様を作り直すのが賢明である。
+- IntersectionObserverが描画完了前に交差を計算するためすべて同時発火する欠陥
 
 ### 最適化
 
@@ -328,16 +330,14 @@ Markdownに本当に必要な仕様はSecuremarkのクラス化制約のよう
     - 文脈依存構文を追加不可能(要解析戦略変更)
   - 構文解析の破綻(文脈依存言語の文脈自由言語としての解析を仕様化したことによる破綻)
     - 二重リンク(`[<a@b>]()`)の生成
-      -二重リンク自体は回避可能で杜撰なだけだが文脈依存構文として解析できないことが根本原因
-    - 画像のalt(`![*a*]()`, `![![a]()`)をMarkdownとして解釈
-      - 再帰的バックトラック回避の必要上修正不可能
+    - 画像のalt(`![*a*]()`, `![![a]()]()`)をMarkdownとして解釈
     - リンクのURLを効率的に解析不可能
       - altはまだしもURLは文脈依存構文としての解析を避けられないため再帰もまた避けられず公式デモページのCommonMarkで`[](`を1万回程度繰り返しただけで解析時間が1秒を超える
       - この欠陥は入れ子数を制限することで回避可能だがこれはCommonmarkは文脈依存構文全般に入れ子数制限を要することを意味する
-      - CommonMarkは最初のバージョンから数年後にこの欠陥を入れ子数制限により修正しこれにより最悪計算量が当初の想定の2nから32nへと32倍に劇的に悪化したことから文脈自由言語および最小計算量としての設計と開発が破綻し失敗に終わったことが明らかである
+      - CommonMarkは最初のバージョンから数年後にこの欠陥を入れ子数制限により修正しこれにより最悪計算量が当初の想定の1nから32nへと32倍に劇的に悪化したことから文脈自由言語および最小計算量としての設計と開発が破綻し失敗に終わったことが明らかである
       - GFMも`[0]([1]()(...[33]()...))`で32回の再帰的バックトラックを行い最悪計算量が32nであることが確認できる
-      - これほど計算量が悪ければ入れ子数制限付き文脈依存言語と大差ない計算量であり素直に文脈依存言語として作り直したほうが遥かに拡張性と発展性が高く優れている
-      - 計算資源は使うためにあるにもかかわらず言語と一致しない不適切な解析方法を使用してまでこの程度の計算資源を惜しんで人間に不便と不自由を強いて生産性を下げるのは本末転倒である
+      - これほど計算量が悪ければ適切に設計された文脈依存言語より悪い計算量であり素直に文脈依存言語として作り直したほうが遥かに拡張性と発展性が高く優れている
+      - 計算資源は使うためにあるにもかかわらず言語と一致しない不適切な解析方法を使用してまでこの程度のわずかな計算資源を惜しんで人間に不便と不自由を強いて生産性を下げるのは本末転倒である
       - 計算機は人間の生産性に奉仕しなければならない
 - タブまたは4スペース以上で字下げ不可能(要構文削除)
 - 情報の再利用困難性
@@ -373,7 +373,7 @@ flanking*!?*
 ### djotの解析規則の問題点
 
 次の公式声明の通り解析規則が構文ごとに定義されず先に閉じられた構文を優先する異常な解析規則になっている。
-すべてをスタックベースで解析するために異常な解析規則に歪んでいる。
+構文解析をスタックベースで行うために異常な解析規則に歪んでいる。
 
 ```
 Most inline syntax is defined by opening and closing delimiters that surround inline content, defining it as emphasized, or as link text, for example. The basic principle governing “precedence” for inline containers is that the first opener that gets closed takes precedence. Containers can’t overlap, so once an opener gets closed, any potential openers between the opener and the closer get marked as regular text and can no longer open inline syntax. For example, in
@@ -389,32 +389,20 @@ the regular emphasis opened by the first _ gets closed by the second _, at which
 it goes just the opposite way.
 ```
 
-結果として文脈の違いを考慮できなくなっている。
+構文すなわち文脈を自然に分離して入れ子にできないということはCommonMarkと同じく拡張困難な設計の言語ということである。
+
+このため文脈を区別しない挙動によるバグが発生する。
 
 ```
 _[a](file_name)
 -> <em>[a](file</em>name)
-```
-
-これにより常識的な期待に容易に反して頻繁にリンクが破壊される。
-自然に構文すなわち文脈を分離して入れ子にできないということはCommonMarkと同じく拡張困難な設計ということである。
-
-二重リンクも除去できていない。
 
-```
-[[a](b)](c)
--> <a href="c"><a href="b">a</a>
-```
-
-変なバグり方をする。
-
-```
 []([]())
 _[a](file_name)
 -> <a href="[]())_[a](file_name"></a>
 ```
 
-すなわち一般的な通常の文法規則に従っておらずCommonMarkと同じく特定の実装技術を使用するために設計が根本的に歪んでいる。バックトラックと計算量を最小化するという戦術的開発目標と技術的手段のために他のすべてを犠牲にしており総じて手段に目的を従わせ歪ませる開発者の人間性と能力の低さが見て取れる。
+すなわち一般的な通常の文法規則に従っておらずCommonMarkと同じく特定のバックトラック回避技術を使用するために設計と文法規則が根本的に歪んでいる。しかも設計と文法を歪めてまでバックトラック排除に固執していながらHTMLや正規表現ではバックトラックが多発しているため設計を歪めてまでバックトラック排除に固執する意味がなくMarkdownの主要構文に限ってバックトラックを完全排除する無意味な自己満足のために異常な解析規則を強いる非常に不自然で歪んだ言語になっている。CommonMarkとdjotはいずれもバックトラックと計算量を中途半端に最小化するという自己満足と技術的手段のために他のすべてを犠牲にしており総じて手段に目的を従わせ歪ませる開発者の人間性と能力の低さが見て取れる。
 
 ### トランスクルージョン
 

package/dist/index.js

@@ -1,4 +1,4 @@
-/*! securemark v0.294.1 https://github.com/falsandtru/securemark | (c) 2017, falsandtru | UNLICENSED License */
+/*! securemark v0.294.3 https://github.com/falsandtru/securemark | (c) 2017, falsandtru | UNLICENSED License */
 (function webpackUniversalModuleDefinition(root, factory) {
 	if(typeof exports === 'object' && typeof module === 'object')
 		module.exports = factory(require("Prism"), require("DOMPurify"));
@@ -2869,7 +2869,7 @@ Object.defineProperty(exports, "__esModule", ({
 exports.lazy = void 0;
 function lazy(builder) {
   let parser;
-  return input => parser !== undefined ? parser(input) : (parser = builder())(input);
+  return input => (parser ??= builder())(input);
 }
 exports.lazy = lazy;
 
@@ -3235,6 +3235,7 @@ class List {
   constructor(nodes) {
     this.length = 0;
     this.head = undefined;
+    this.last = undefined;
     if (nodes === undefined) return;
     for (let i = 0; i < nodes.length; ++i) {
       this.push(nodes[i]);
@@ -3243,40 +3244,43 @@ class List {
   get tail() {
     return this.head?.next;
   }
-  get last() {
-    return this.head?.prev;
-  }
   insert(node, before) {
+    if (before === undefined) return this.push(node);
+    if (before === this.head) return this.unshift(node);
     if (++this.length === 1) {
-      return this.head = node.next = node.prev = node;
+      return this.head = this.last = node;
     }
-    const next = node.next = before ?? this.head;
+    const next = node.next = before;
     const prev = node.prev = next.prev;
     return next.prev = prev.next = node;
   }
   delete(node) {
     if (--this.length === 0) {
-      this.head = undefined;
+      this.head = this.last = undefined;
     } else {
       const {
         next,
         prev
       } = node;
-      if (node === this.head) {
-        this.head = next;
-      }
-      // Error if not used.
-      prev.next = next;
-      next.prev = prev;
+      prev === undefined ? this.head = next : prev.next = next;
+      next === undefined ? this.last = prev : next.prev = prev;
     }
     node.next = node.prev = undefined;
     return node;
   }
   unshift(node) {
-    return this.head = this.insert(node, this.head);
+    if (++this.length === 1) {
+      return this.head = this.last = node;
+    }
+    node.next = this.head;
+    return this.head = this.head.prev = node;
   }
   push(node) {
-    return this.insert(node, this.head);
+    if (++this.length === 1) {
+      return this.head = this.last = node;
+    }
+    node.prev = this.last;
+    return this.last = this.last.next = node;
   }
   shift() {
     if (this.length === 0) return;
@@ -3284,21 +3288,22 @@ class List {
   }
   pop() {
     if (this.length === 0) return;
-    return this.delete(this.head.prev);
+    return this.delete(this.last);
   }
   import(list, before) {
     if (list.length === 0) return this;
     if (this.length === 0) {
       this.head = list.head;
-      this.length += list.length;
+      this.last = list.last;
+      this.length = list.length;
       list.clear();
       return this;
     }
     const head = list.head;
     const last = list.last;
-    const next = last.next = before ?? this.head;
-    const prev = head.prev = next.prev;
-    next.prev = last;
+    const next = last.next = before;
+    const prev = head.prev = before?.prev ?? this.last;
+    next === undefined ? this.last = last : next.prev = last;
     prev.next = head;
     this.length += list.length;
     list.clear();
@@ -3306,14 +3311,13 @@ class List {
   }
   clear() {
     this.length = 0;
-    this.head = undefined;
+    this.head = this.last = undefined;
   }
   *[Symbol.iterator]() {
     for (let node = this.head; node && this.head;) {
       const next = node.next;
       yield node;
       node = next;
-      if (node === this.head) break;
     }
   }
   flatMap(f) {
@@ -3322,7 +3326,6 @@ class List {
       const next = node.next;
       acc.import(f(node));
       node = next;
-      if (node === this.head) break;
     }
     return acc;
   }
@@ -3331,15 +3334,13 @@ class List {
       const next = node.next;
       acc = f(acc, node);
       node = next;
-      if (node === this.head) break;
     }
     return acc;
   }
   foldr(f, acc) {
-    for (let node = this.head?.prev; node && this.head;) {
+    for (let node = this.last; node && this.head;) {
       const prev = node.prev;
       acc = f(node, acc);
-      if (node === this.head) break;
       node = prev;
     }
     return acc;
@@ -3349,7 +3350,6 @@ class List {
       const next = node.next;
       if (f(node)) return node;
       node = next;
-      if (node === this.head) break;
     }
   }
 }
@@ -3375,7 +3375,7 @@ exports.List = List;
 Object.defineProperty(exports, "__esModule", ({
   value: true
 }));
-exports.failsafe = exports.clean = exports.subinput = exports.input = exports.Data = exports.List = void 0;
+exports.failsafe = exports.subinput = exports.input = exports.Data = exports.List = void 0;
 const data_1 = __webpack_require__(3602);
 Object.defineProperty(exports, "List", ({
   enumerable: true,
@@ -3414,19 +3414,6 @@ function subinput(source, context) {
   };
 }
 exports.subinput = subinput;
-function clean(context) {
-  const {
-    source,
-    position
-  } = context;
-  for (const p of Object.keys(context)) {
-    context[p] = undefined;
-  }
-  context.source = source;
-  context.position = position;
-  return context;
-}
-exports.clean = clean;
 function failsafe(parser) {
   return input => {
     const position = input.context.position;
@@ -4102,7 +4089,7 @@ const note_1 = __webpack_require__(165);
 const url_1 = __webpack_require__(1904);
 const array_1 = __webpack_require__(6876);
 function bind(target, settings) {
-  let context = {
+  const context = {
     ...settings,
     host: settings.host ?? new url_1.ReadonlyURL(location.pathname, location.origin)
   };
@@ -4429,13 +4416,13 @@ const figure_1 = __webpack_require__(1657);
 const note_1 = __webpack_require__(165);
 const url_1 = __webpack_require__(1904);
 const dom_1 = __webpack_require__(394);
-function parse(source, opts = {}, context) {
+function parse(source, options = {}, context) {
   const url = (0, header_2.headers)(source).find(field => field.toLowerCase().startsWith('url:'))?.slice(4).trim() ?? '';
   source = !context ? (0, normalize_1.normalize)(source) : source;
   context = {
-    host: opts.host ?? context?.host ?? new url_1.ReadonlyURL(location.pathname, location.origin),
+    host: options.host ?? context?.host ?? new url_1.ReadonlyURL(location.pathname, location.origin),
     url: url ? new url_1.ReadonlyURL(url) : context?.url,
-    id: opts.id ?? context?.id,
+    id: options.id ?? context?.id,
     caches: context?.caches,
     resources: context?.resources
   };
@@ -4450,9 +4437,9 @@ function parse(source, opts = {}, context) {
       value
     }) => void acc.push(value) || acc, []) ?? []));
   }
-  if (opts.test) return node;
-  for (const _ of (0, figure_1.figure)(node, opts.notes, context));
-  for (const _ of (0, note_1.note)(node, opts.notes, context));
+  if (options.test) return node;
+  for (const _ of (0, figure_1.figure)(node, options.notes, context));
+  for (const _ of (0, note_1.note)(node, options.notes, context));
   return node;
 }
 exports.parse = parse;
@@ -4514,7 +4501,7 @@ exports.block = (0, combinator_1.reset)({
     recursions: [10 || 0 /* Recursion.block */, 20 || 0 /* Recursion.blockquote */, 40 || 0 /* Recursion.listitem */, 20 || 0 /* Recursion.inline */, 20 || 0 /* Recursion.bracket */, 20 || 0 /* Recursion.terminal */]
   },
   backtracks: {}
-}, error((0, combinator_1.union)([input => {
+}, error((0, combinator_1.union)([source_1.emptyline, input => {
   const {
     context: {
       source,
@@ -4570,7 +4557,7 @@ exports.block = (0, combinator_1.reset)({
     default:
       if ('0' <= fst && fst <= '9') return (0, olist_1.olist)(input);
   }
-}, source_1.emptyline, paragraph_1.paragraph])));
+}, paragraph_1.paragraph])));
 function error(parser) {
   const reg = new RegExp(String.raw`^${"\u0007" /* Command.Error */}.*\n`);
   return (0, combinator_1.recover)((0, combinator_1.fallback)((0, combinator_1.open)("\u0007" /* Command.Error */, ({
@@ -6393,7 +6380,7 @@ const parser_1 = __webpack_require__(605);
 const combinator_1 = __webpack_require__(3484);
 const link_1 = __webpack_require__(3628);
 const source_1 = __webpack_require__(8745);
-exports.url = (0, combinator_1.lazy)(() => (0, combinator_1.rewrite)((0, combinator_1.open)(/(?<![0-9a-z][.+-]?)https?:\/\/(?=[\x21-\x7E])/y, (0, combinator_1.precedence)(1, (0, combinator_1.some)((0, combinator_1.union)([(0, combinator_1.verify)(bracket, ns => ns.length > 0), (0, combinator_1.some)(source_1.unescsource, /([-+*=~^_/])\1|[,.;:!?]{2}|[-+*=~^_,.;:!?]?(?=[\\"`\[\](){}<>（）［］｛｝|]|[^\x21-\x7E]|$)/y)]), undefined, [[/[^\x21-\x7E]|\$/y, 9]])), false, [3 | 0 /* Backtrack.autolink */]), (0, combinator_1.union)([(0, combinator_1.constraint)(1 /* State.autolink */, (0, combinator_1.state)(1 /* State.autolink */, (0, combinator_1.convert)(url => `{ ${url} }`, link_1.unsafelink, false))), ({
+exports.url = (0, combinator_1.lazy)(() => (0, combinator_1.rewrite)((0, combinator_1.open)(/(?<![0-9A-Za-z][.+-]?)https?:\/\/(?=[\x21-\x7E])/y, (0, combinator_1.precedence)(0, (0, combinator_1.some)((0, combinator_1.union)([(0, combinator_1.some)(source_1.unescsource, /(?<![-+*=~^_,.;:!?]|\/{3})(?:[-+*=~^_,.;:!?]|\/{3,}(?!\/))*(?=[\\$"`\[\](){}<>（）［］｛｝|]|[^\x21-\x7E]|$)/y), (0, combinator_1.precedence)(1, (0, combinator_1.verify)(bracket, ns => ns.length > 0))]), undefined, [[/[^\x21-\x7E]|\$/y, 9]])), false, [3 | 0 /* Backtrack.autolink */]), (0, combinator_1.union)([(0, combinator_1.constraint)(1 /* State.autolink */, (0, combinator_1.state)(1 /* State.autolink */, (0, combinator_1.convert)(url => `{ ${url} }`, link_1.unsafelink, false))), ({
   context: {
     source
   }
@@ -8200,7 +8187,6 @@ Object.defineProperty(exports, "__esModule", ({
   value: true
 }));
 exports.validate = exports.segment = exports.MAX_INPUT_SIZE = exports.MAX_SEGMENT_SIZE = void 0;
-const parser_1 = __webpack_require__(605);
 const combinator_1 = __webpack_require__(3484);
 const heading_1 = __webpack_require__(2778);
 const codeblock_1 = __webpack_require__(9194);
@@ -8238,18 +8224,14 @@ const parser = (0, combinator_1.union)([input => {
 }, (0, combinator_1.some)(source_1.contentline, exports.MAX_SEGMENT_SIZE + 1), (0, combinator_1.some)(source_1.emptyline, exports.MAX_SEGMENT_SIZE + 1)]);
 function* segment(source) {
   if (!validate(source, exports.MAX_INPUT_SIZE)) return yield `${"\u0007" /* Command.Error */}Too large input over ${exports.MAX_INPUT_SIZE.toLocaleString('en')} bytes.\n${source.slice(0, 1001)}`;
-  const context = {
-    source,
-    position: 0
-  };
-  const input = {
-    context
-  };
-  for (; context.position < source.length;) {
-    const {
+  for (let position = 0; position < source.length;) {
+    const context = {
+      source,
       position
-    } = context;
-    const result = parser(input);
+    };
+    const result = parser({
+      context
+    });
     const segs = result.length > 0 ? result.foldl((acc, {
       value
     }) => void acc.push(value) || acc, []) : [source.slice(position, context.position)];
@@ -8257,7 +8239,7 @@ function* segment(source) {
       const seg = segs[i];
       validate(seg, exports.MAX_SEGMENT_SIZE) ? yield seg : yield `${"\u0007" /* Command.Error */}Too large segment over ${exports.MAX_SEGMENT_SIZE.toLocaleString('en')} bytes.\n${seg}`;
     }
-    (0, parser_1.clean)(context);
+    position = context.position;
   }
 }
 exports.segment = segment;
@@ -8854,7 +8836,8 @@ const alias_1 = __webpack_require__(5413);
 const parser_1 = __webpack_require__(605);
 const dom_1 = __webpack_require__(394);
 function* unwrap(nodes) {
-  for (const node of nodes ?? []) {
+  if (nodes === undefined) return;
+  for (const node of nodes) {
     yield node.value;
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "securemark",
-  "version": "0.294.1",
+  "version": "0.294.3",
   "description": "Secure markdown renderer working on browsers for user input data.",
   "private": false,
   "homepage": "https://github.com/falsandtru/securemark",

package/src/combinator/control/manipulation/clear.ts

@@ -1,5 +1,5 @@
-import { Parser, List, CtxOptions } from '../../data/parser';
+import { Parser, List, Ctx } from '../../data/parser';
 
-export function clear<D extends Parser<unknown, C>[], C extends CtxOptions>(parser: Parser<unknown, C, D>): Parser<never, C, D> {
+export function clear<D extends Parser<unknown, C>[], C extends Ctx>(parser: Parser<unknown, C, D>): Parser<never, C, D> {
   return input => parser(input) && new List();
 }

package/src/combinator/control/manipulation/lazy.ts

@@ -4,7 +4,5 @@ export function lazy<P extends Parser<unknown>>(builder: () => P): P;
 export function lazy<N>(builder: () => Parser<N>): Parser<N> {
   let parser: Parser<N>;
   return input =>
-    parser !== undefined
-      ? parser(input)
-      : (parser = builder())(input);
+    (parser ??= builder())(input);
 }