{overflow: hidden}{進捗記録}{希哲16年3月2日の開発}{希哲16年3月2日の進捗}{希哲16年3月2日}{position: relative}{overflow: clip}{調整していく}{揃わなくなる}{縦位置}...=}(83)

{希哲16年3月2日10歩 K#F85E/E74C-FDA9}

=}
{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}...=}(94)

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

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{デラング}{進捗記録}{廃止}{組み合わせた}{キーボード記法}{見送った}{書き間違い}{下境界線}{上境界線}{邪魔臭い}...=}(111)

{希哲16年1月17日17歩 K#F85E/E74C-835A}

キーボード記法改良終了

従来二重角括弧を使った [[X]] 記法に加え,アンダースコア組み合わせた [_X_] 記法使えるようにした

旧記法近いうちに廃止し,ウィキ互換輪結記法転用する。ハッシュタグ同様,単純に全知検索飛ばすだけだが,他サービスからの移行者デライト触りやすくなったり,デライト向け文書書き直しやすくする効果見込める

大きな用途変更であるため,時印によって適用版存切り替えることになりそうだ。

11日14歩検討方向性定まっていた旧記法導入した昨年3月11日はまだデラング整備最初期で,あまり他サービス他言語との互換性重視しておらず,他サービス採用例多かった二重角括弧による輪結キーボード記法使うことも,独自性を出すのに良いだろうという程度にしか考えていなかった

最近デラングが,デライトにとっての利益損なわない限り他サービス他言語との互換性最大化するという方針になっていることに加え,単純に旧記法視認性の悪さ気になっていたこともあった。最近ではほとんど自分で使っていなかった

[[Ctrl]] のようにキー名長さがあればまだいいが,[[X]] では流石に記号邪魔臭い[_X_] という記法は当時検討した記憶があるが,[X] に対して物足りず決め手に欠ける感じたか,なんとなく見送っていた[[X]] は「キー立体感を表現しているように見えなくもない」希哲15年3月11日2歩思っていたが,<kbd>装体デライトも含めて,四方み,立体感を出すため上境界線よりも下境界線目立たせるという形になることが多いため [_X_] の方がむしろ装体近い

逆括点を使った [`X`] という記法採用例を見かけて悪くない思ったが,まだ普及度低い上,これは `[X]` との書き間違い続出しそうだと感じたたため見送った[_X_] ならその問題もなく,直感性でこれに勝るものはなさそうだ。

<kbd>入れ子にすることも出来るので,[_Ctrl_] + [_X_] のような組み合わせ記法として扱うことを考えたが,実用上大きな変化はないはずなので後回し

{実装済みのデラング記法}{希哲16年1月17日の開発}{キー記法}{<kbd>}{キー操作記法}{キー入力記法}{キートップ記法}{記法}{キーボード}=}(9)

{キーボード記法 K#F85E/E74C-70AF}

(「キー記法」でないのは一見して意味が分かりにくいため)

[[X]] から [_X_] へ。

[[Ctrl]] + [[X]]Ctrl+X

[_Ctrl_] + [_X_]Ctrl+X

Ctrl+X Ctrl+FC-x C-f Emacs 風表記に使ってもいい。

{希哲館}{一日一文}{<img>}{HTML5}{希哲館訳語}{英語}{英単語}{略す}{論組}{交度}...=}(112)

{交度英語のすすめ K#F85E/E74C-244F}

希哲館における珍奇語彙といえば「日本語史上最大の翻訳語体系」こと希哲館訳語ばかりが注目されがちだが,実は,もう一つそれに負けず劣らず珍奇な言語関連望事プロジェクトがある。それが「交度英語」(Code English),略して「交語」(Codish)だ。

これは主に希哲館情報技術体系利用しているもので,簡単に言えば,「英語勘報機コンピューター向けに簡略化した人工言語」だ。


勘報コンピューティング世界では,技術者であれば誰でも理解出来るような略語というものが多数存在する。例えば,std〈standard〉int〈integer〉str〈string〉……といった具合だ。多くは「歴史的経緯」で定着したものだ。

一方で,こうした略語使用を避けるという文化優勢になっている。その主な理由は,「共有しにくい」からだ。特に新しい論組プログラミング言語では,英語略さずに使う傾向があるため,妙に冗長交度コードが増えた。

はっきり言おう。私は,これが非常に馬鹿げた考え方,いわば「略さない病」であると思っている。この病気によって世界から失われた効率性金額換算すれば天文学的なものになるに違いない。

よく考えてもみてほしい。略語というのは,どんな専門分野でも記録情報交換効率化のために自然発生するものだ。数学の一見意味不明略語記法は,数学者本質的仕事専念するために編み出したものだろう。日夜神経を磨り減らして交度と向き合う情報技術者がそれを封じるのは,狂気の沙汰と言ってもいい。

実際のところ,「略語を使わないルール徹底されているかというと,そうではない。例えば,String str; なんて記述は世の中に溢れかえっている。C++ には shared_ptr(pointer)Java には println()(line)なんてものがある。「モダン」なはずの HTML5 にも img(image)やら kbd(keyboard)やら残っている。こうした混在が当たり前になっているのが現状だ。なぜなら,「略語を使わない」というのは本来不自然なこと,無理のあることだからだ。

長い方に合わせるのは無理なのだから,短い方に合わせればいい。共有しにくいなら,「略語を使わない」のではなく,「略語の辞書を作る」ことを考えればいい。頻繁に使うものなら人間は慣れる。これがつまり,交度英語考え方だ。

交度英語では,すでに定着している英略語を基礎に,実践を通じて新しい略語提案問題があれば修正しながら語彙を作り上げていく。

具体的には,論組をしながら,どうせばいいのか分からない英単語にあたった時,私はまず適当に略してみて,それをデライト検索する。他に前例があればそれと突き合わせて修正することもあるし,無ければどういう意図で使ったかを描き出していく。これを繰り返すことで,デライトが自然と辞書役割を果し,妥当略語の使い方に導いてくれるようになる。

これは基本的に希哲館訳語で行っていることと同じであり,デルンデライトがはじめて可能にしたことでもあるのだろう。

希哲館ではまだ素交ソースコード公開などはしていないので,交度英語を使った交度の実例としてすぐに見せられるものは少ないが,最近書いた「JavaScript の beforebegin,afterbegin,beforeend,afterend に代わる要素位置記法」などにはその片鱗が見えるかもしれない。

いずれ『希哲辞典』のように辞典として整えて公開することも考えているが,まずは考え方を紹介しておきたかった。

{<kbd>}

{}