{進捗記録}{希哲16年2月18日の開発}{あれ}{文章の流れ}{左右矢印}{下矢印}{上矢印}{使うべきではない}{右矢印}{使われない}...=}(171)

{希哲16年2月18日13歩 K#F85E/E74C-E223}

進捗時限記録中略

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

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

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


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

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


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

前 <|> 後
前 <|
|> 後

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

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


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

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

=}
{デラング}{進捗記録}{希哲16年2月14日の開発}{損われる}{本質的ではない}{記述しやすい}{珍しくない}{大規模サイト}{迷惑行為対策}{運営上の都合}...=}(65)

{希哲16年2月14日15歩 K#F85E/E74C-5780}

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

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

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

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

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

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

=}
{デラング}{進捗記録}{まとまりそう}{設計の中心}{留めたい}{加えていく}{開いて欲しい}{煩雑過ぎる}{現実的に}{調整する}...=}(96)

{希哲16年2月2日12歩 K#F85E/E74C-6AB3}

進捗時限記録中略

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

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

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

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

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

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

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

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

=}
{rgx_T}{s_T の補助函数}{進捗記録}{幸いした}{書き換え作業}{置換作業}{必要な時期}{置換した}{冗長版}{置換する}...=}(69)

{希哲16年1月28日16歩 K#F85E/E74C-C804}

進捗時限記録中略

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直接使った交度から類型化正規表現への書き換え作業想定より遅滞していたことが幸いして,現時点類型化正規表現多くない

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

=}
{}{進捗記録}{希哲16年1月27日13歩}{漢字一字}{見越した}{訳されている}{伝わりにくい}{意味が狭い}{新たに}{使いやすそう}...=}(106)

{希哲16年1月26日17歩 K#F85E/E74C-79F5}

進捗時限記録中略前後

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

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

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

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

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

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


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

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

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

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

{再検討}

{}