輪郭選り手抜控機能整備。

途中で終了。

鍵仕様を再検討。

鍵 は Aejs/DG/rdrw/K#XXXX/YYYY?dln のように URL 風にするつもりだったが，正規表現との相性が悪いため，いったんアンダースコア区切りで統一することにした（Aejs_DG_rdrw_K#XXXX/YYYY__dln）。

前後景一覧は別として，検索語無指定の場合の輪郭一覧で描写のない他輪郭を非表示にすることを検討。以前からあった案だが，いくつか懸念もあり見送ってきた。

輪郭の展示としては知名のみの輪郭は邪魔に見えることが多いが，非表示にする条件の導入により挙動が複雑になることで多少用者の混乱を招くだろう。読みやすくなる代わりに，内容のあることを書かなくてはならないという誤解で書きにくくなるかもしれない。また，知名のみの輪郭での表現にも有用なものはあるので，全て非表示というのももったいない。かといって，後景輪があるものを例外にすると中途半端で現状と大差ない。

いずれにせよ，自我で輪郭一覧の見せ方を変える仕組みは公開設定機能で整える必要があるので，その時に再検討することにした。

（進捗時限記録中略）

「前後記法」として検討していた記法を「前次記法」に改め，仕様を再検討して終了。

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

以上のように，<- 前 | 次 -> を基本形とし，改行区切りや <- 前，次 -> のみでの記述も可能にすることにした。

デルンにあった類似機能から，「時間（時印）的な前後関係」を表現する記法として「前後記法」と呼んでいたが，文書では新旧にかかわらず読ませたい順序を指定出来る方が便利なので，より汎用的な「前次記法」と位置付け直した。

新旧を表すのに「前」や「次」というのはよく考えるとおかしいという意見もあり，私も何か良い代替表現はないかと考えていたが，慣用表現として定着しているのでこれは仕方ない。前ページ・次ページというように，左開きのページをめくっていく感覚なのだろう（左開き・右開きは書字方向との相性の問題なので，ウェブで右が次になることが多いのは一応合理的ではある）。

前回の検討では，以下のように書いていた。

前 <|> 後
前 <|
|> 後

これは他記法と区別しやすく簡潔ではあるが，見本はともかく少し長い文字列が入ると記号が埋もれがちで直感的とも言い難い。視認性を考えると，行頭・行末に分かりやすい記号があってほしい。

また，<|> はタグ記法で使う予定の </> と紛らわしい。| で始まる長い文字列があると，初心者には表組み記法と誤認される恐れもある。

他記法との区別しやすさ，簡潔性，直感性などを総合的に考慮した結果，最も素直な記法であろう <- 前 | 次 -> に落ち着きつつある。

雑多な考慮点を列挙しておく。

• 引用記法・出典記法・パンくず記法に加えタグ記法で <，> が多用される見込みなので，記法選定は慎重を要する。
  • < 前 | 次 > はタグと紛らわしい。
    • パンくず記法と衝突するため 次 > と短縮することも出来ない。
  • << 前 | 次 >> は検討中の行内出典記法と紛らわしい。
  • <- 前 | 次 -> はしいて言えば編注記法（<!– ... –>）に似ているが，紛らわしいというほどではない。
    • 回避策として <= 前 | 次 => が考えられるが，これは目立たせ方を変えることなどに使える可能性もあり温存しておきたい。
  • 次 -> は，1階層だけのパンくず記法 上 > とぱっと見紛らわしいが，記号の役割が分かっていればそこまで不自然ではない。
• 自然言語の表記慣習にも十分配慮する必要がある。
  • 将来的に普通の左右矢印（←→）を使えるようにしてもいい。
  • 「これ↓」のように，上記・下記の意では上矢印（↑）・下矢印（↓）が使われることが多いため，行頭・行末での左右矢印の用例はかなり限られる。
  • 行頭に左矢印（←）は滅多に使われないので問題ないだろう。
  • 行頭に右矢印（→）は「参照せよ」の意で使うこともあれば，結論・結果などを示す場合に使われることも珍しくないため，前次記法に使うべきではない。
  • 行末に右矢印が使われることは稀だが，しいて言えば「続く→」のように使われることがあるため，比較的前次記法と調和する。
    • 文章の流れを示すことに使われないとも言えないが，いずれにせよ稀少例なので越化で十分か，次行が空行であることを必須とするなどで対応出来る。

越化（エスケープ）周りの客体表現化を考えるついでに文字参照の越化について再検討して終了。

HTML 越化仕様を決めた昨年5月20日12歩以来，越化目的で使う可能性がある文字参照のみを許容していたが，これは修正し，いったん全ての文字参照を許容することにした。

4日21歩でも再検討したが，越化記法同様，デラングにおける特殊文字を白表方式で管理するのは無理がある。損われる保守性に対して利点が乏しい。

当初は制危というより迷惑行為対策など運営上の都合で必要になるのではないかと思っていたが，Wikipedia はじめ大規模サイトで開放されている例も珍しくなく，少なくともデライトの言語仕様にするほど必要な制限とは言えない。文字参照で制危上致命的な問題があればそれは舞覧の問題だろう。迷惑行為対策としてもあまり本質的ではない。

何か問題があれば制限する，で十分なはずなので，実装都合で制限してもいいことにする。

文字参照には，表示や入力に難がある文字が記述しやすいという有用性も一応ある。

越化に関する検討に関連して，文字参照についても再検討。

今のところ白表方式にしているが，管理の煩雑さに対してあまり利点が無い気がしてきたので，制限の撤廃も視野に入れる。問題が出てきてから制限すれば十分か。

見出し装体についての再検討で終了。

微妙な文字サイズと 1px の下境界線の太さしか違わない <h2> と <h3> の見分けにくさをどうするか考えていたが，目立ち方を大きく変えずにとなると，<h2> の下境界線を二重にするくらいしかなさそうだ。

ついこのあいだ Markdown の見出し記法とこの見出し装体の相性が良いことに気付いて導入を考え始めたので整合性が取れると面白いが，区切り線記法との兼ね合いも考える必要がある。

駒手つながりで駒手記法についても再検討して終了。

先日の検討でコマンド プロンプト，PowerShell への対応方針を決めたが，この際 % にも対応することにした。これで一般的な駒手欄は全て表現出来る。

$ [駒手]
% [駒手]
# [駒手]
:> [コマンド プロンプトの駒手]
PS> [PowerShell の駒手]

（進捗時限記録中略）

コンマ駒手について考えたついでに，描写選り手についての再確認・再検討で終了。

現状の開閉式選り手は，やはり気に入っている部分でもあり維持するしかなさそうだ。閲覧と編集にはそれぞれ最適な用合いがある。

そして，この描写選り手はやはり <textarea> に近い単純なものが良い。WYSIWYG 選り手は多機能化すればするほど挙動の好き嫌いも出てくるし，多様な入力環境に対応出来ない場合も出てくる。高い実装コストの割に失うものも大きい。

そもそも，デラングのような軽標記言語の役割は普文を読み書きしやすくすることであり，そこはデラングに頼っていい。

換配後編集支援・部品単位編集という考え方が出来てから基本的にはこの方針だが，最近，下見機能も含めて輪郭選り手の全体像がはっきりしてきたこともあり，現状単なる <textarea> の描写選り手に加えるべき機能も見えてきた。

中途半端になる懸念から，全く機能を加えないという選択肢もあった。ただ，これは問題の方が大きくなりそうだ。例えば，無番輪符を書いてから下見か完了して輪郭小窓で調整するというのは，現実的に考えると煩雑過ぎる。やはり，その場で輪郭小窓が開いて欲しい。

ただ，昔から考えてきた輪符の折り畳みといった機能は加えない。こういった部分は，せいぜい色付けや輪結化に留めたい。このあたりは部品単位編集との使い分けも考えながら，あくまでも単純性・保守性を損なわない範囲で，デラング編集支援としての機能を加えていくことにした。

部品単位編集も含めて，デラングを設計の中心に据えることで上手くまとまりそうだ。ここでもデラング整備が大きな意味を持ってくる。

（進捗時限記録中略）

Cμ 文字列処理改良，rgx_T の置換道手の引数順序変更。

作業方針の再検討で終了。

あとは rgx_T::rpl() の引数順序変更で rgx_T の置換道手の引数順序変更は完了だが，これまでの道手の呼び出し箇所が Dex のごく一部に限られていたのに対し，.rpl() は Cμ 初期からあちこちで使っている置換道手なので，少し複雑な作業になる。

まず，いったん .rpl() を適当な名前に変えて無効化し，呼び出し箇所を引数順序変更済みの .rpl_glb() あるいは客体表現に置換するか，正規表現・客体表現を使うまでもない処理なら s_T の補助函数に置換する。現時点で .rpl_glb() は .rpl() の冗長版に過ぎないため，置換したままにしておいて問題ない。交度整理をしていけば自然に戻るはずなので，あえて再置換はしないことにした。

置換作業に入る前に，作業に必要な s_T の補助函数整備も必要だが，既存の「類型化正規表現」（rgx_x_T）の置換道手も旧式の引数順序にならっているため，まず最初に客体表現（ojx_x_T）への書き換え作業を済ませることにした。rgx_T を直接使った交度から類型化正規表現への書き換え作業が想定より遅滞していたことが幸いして，現時点で類型化正規表現は多くない。

いずれにせよ，正規表現の総点検や客体表現への書き換えが必要な時期であり，保守性と効率性の大きな向上が見込める良い機会だ。

（進捗時限記録中略・前後）

長いこと決めかねていた「ソース」（source）の暫定訳語として「素出（そしゅつ）」を採用することを検討・決定して終了。

希哲8年12月13日には「素成（そせい）」という訳語を描き出していたが，なんとなく使いにくく，ほとんど使わなかった。

ただ，この案から，どの道「素」で始まる訳語になるだろうということは確信していたため，「素交」（ソース コード）や「素譜」（ソース ファイル）という略語の形では比較的よく使っていた。このように，他の訳語と組み合わせて略した時などに分かりやすい利点が大きかった。「オリジナル」の意と区別しにくい「原〜」などと差別化しやすく，音写性も申し分ない。

「素出」は希哲12年2月27日に描き出していた案だが，これらの略語で間に合うことが多かったこともあり，採用にはいたっていなかった。最近，デラング整備の中で単純にソースに対応する訳語が欲しいと思うことが多くなっていたので再検討してみることにした。

「素泉」「素種」「素資」等々の案もあったが，どれも一見して意味が掴みにくい。新たに「素書」という案を考えてみたが，これも若干意味が狭い。それに比べると，「素出」は平たくソースの全体訳語として使いやすそうだ。

「素出」で特に問題なさそうだが，まずは暫定訳語として使ってみて，上等訳語とするかどうか決めることにした。

ついでに，「オープンソース」のオープンをどう訳すかも考えた。「大触れ」という案もあったが，伝わりにくいだろう。

平たく表現するなら，「公開」は誤解の余地が大きいので「開放」しかなそうだ。あまり使わなかったが，希哲14年1月頃，「開素」をオープンソースの暫定訳語としたことを思い出した。これも「素」で始まるソースの訳語を見越したもので，やはりオープンも漢字一字で表すなら「開」以外ないだろうと考えていた。

答え合わせ感覚で中国語での例を調べてみると，やはり〈开放〉と訳されている。

とりあえず，オープンソースは「開放素出」とし，「開素」はその省略形と位置付け直すことにした。