{デラング文書}{希哲15年6月28日の開発}{表組み記法}{希哲15年6月28日の進捗}{希哲15年6月28日の進捗時限}{希哲15年6月28日}{テーブル記法}{定表記法}{デラング整備}{仕様検討}...=}(21)

{希哲15年6月28日9歩 K#F85E/A-E74C-2595}

進捗時限記録中略)

デラング整備表組み記法仕様検討

およそ6歩分3時間ほどかかっていったん終了。

簡潔性柔軟性直感性を兼ね備えた記法の全体像が概ね出来た。

表組み記法」に覚え書き程度にまとめたが,いちいち解説している時間は無いので実装してからデラング文書にまとめる。

今日から,これまで使っていた「定表記法」や「テーブル記法」の代わりに「表組み記法」とすることにした。

=}
{希哲15年5月12日の開発}{DBG()}{出力形式}{標準違了出力}{def_dbg.h}{ERR()}{DBG_DEX()}{希哲15年5月12日の進捗時限}{希哲15年5月12日}{希哲15年5月12日の進捗}...=}(24)

{希哲15年5月12日10歩 K#F85E/A-E74C-A568}

def_dbg.h調整

途中で終了。

標準違了出力共通の ERR()追加,これを利用し DBG()再定義DBG_DEX() を追加した。

これまで,DBG() では長いこと以下のような出力形式採用していた。これも少し再検討したが,直感性視認性を上手く両立させており,ごちゃごちゃした出力の中でも分かりやすいので基本的には踏襲することにした。

!? main.u:123 << hello debug

今回,これに加え,マクロ名を加えることにした。

!? DBG;main.u:123 << hello debug
!? DBG_DEX;main.u:123 << hello Dex debug
=}
{希哲15年4月23日の開発}{方針検討}{プロポーショナル}{フォント調整}{希哲15年4月23日の進捗時限}{希哲15年4月23日の進捗}{希哲15年4月23日}{希哲15年3月10日11歩}{描写選り手}{整合的}...=}(24)

{希哲15年4月23日12歩 K#F85E/A-E74C-16C6}

描写選り手フォント調整

描写選り手は等幅フォントで良いとして,よく考えると,知名欄全知検索窓はどうするという問題があった。

描写欄が等幅で知名欄プロポーショナルというのも違和感があるため,両方が開いている場合は等幅で統一,知名欄だけが開いている場合は直感性を重視しプロポーショナルにしておくことにした。これなら全知検索窓がプロポーショナルでも整合的だ。

知名欄描写欄は同時に開いている場合合体させることを決めている3月10日11歩ため,これで自然に見えるだろう。

細かい調整は追い追いするとしてまずは方針検討のみで終了。

{共通言語}{あれ}{デライト・アイコン集制作の様子}{希哲14年9月21日のツイスト}{希哲14年9月21日}{デライト・アイコン集}{1px}{デライト}{用者体験}{ツイスト}...=}(22)
{デラング}{希哲14年7月27日の開発}{!?}{??}{検索種別}{描写検索}{補助的}{後方一致検索}{前方一致検索}{特殊記号}...=}(61)

{希哲14年7月27日3歩 K#F85E/A-5B28-31DB}

デライト検索における部分一致検索全文検索仕様について大まかな方針を決め終了。

現状,デルン初期から引き継いでいる輩符による部分一致検索が残っているが,輩符は末尾ならともかく先頭に置くのは一般に使われる除外検索と紛らわしいという問題がある。

代わりにアスタリスクを使うという手も考えた。技術者にとっても分かりやすく,一般的にも伏せ字で使われることがあり,直感性に大きな問題はない。特殊記号であることは明らかなので混同の恐れも小さい。ただ,アスタリスク描写記法デラング)において見出し強調などに使うことを想定しており,その場合一貫性に欠ける。

そこで,「...」を使うことを考えた。例えば,「検索語...」で前方一致検索,「...検索語」で後方一致検索となる。「」や「・・・」で代用してもいい。普遍的省略記号であり,直感性アスタリスクに勝る。唯一の難点として素早く入力しにくいというのはあるが,全知検索ではあくまでも補助的な手段であるためこのくらいで丁度いいかもしれない。

ついでに将来的に全文検索などに対応をする場合の用合いについても検討

そのうち,知名検索だけではなく描写検索も含めた全文検索への要求も高まるだろう。現時点で想定しておかなければならない検索種別は,現状の知名のみ検索に加え,描写のみ検索,知名・描写検索の3種となる。これらを上手く切り替えられる方式を考えておきたい。

現状,?ボタンに使っているため,これを拡張して,検索語の末尾に ?! を加えることで検索種別を切り替えられる方式を考案した。末尾にこれらの文字を加えると,ボタンも ??!? に変化する。例えば,知名・描写両方を検索したい場合は ?? に,描写のみを検索したい場合は !? のようにする。!論組では否定の意で使われるため,知名は検索せず描写は検索する,という状態を上手く表している。

自然で分かりやすいが,自然過ぎることによる問題もある。題名などで疑問符感嘆符を使うものは珍しくないため,上手く切り分ける方法も考えておく必要がある。一番分かりやすいのは,記号の前に空白を置くことだが,フランス語のように言語によっては既にそういう習慣がある。末尾に空白を置いて無効化出来るなど,いくつか代替手段も必要だろう。

細部に課題は残るが,大まかな方針としてはこれで間違いないだろう。

{希哲14年7月11日の日記}{大きな進展}{Enter キー}{新ダブルクリック方式}{ダブルクリック方式}{Ctrl キー}{希哲14年7月11日}{作業量}{用合い}{諸場用合い}...=}(32)

{希哲14年7月11日の開発 K#F85E/A-5B28-75D5}

3月頃からダブルクリック方式代替案について考え続けてきたが,Ctrl キーEnter キー併用するように改良した新ダブルクリック方式採用することにした。大きな進展と言える。

代替案は考えられるだけ考えたが,使いやすさ直感性単純性諸場用合いとの一貫性,既存操作との干渉など,様々な観点から満足いくものが見つからず,結局はダブルクリック方式再評価改良に繋がった。

ボタンを作ったり,凝った独自事象追加しようかなどとも考えていたので,結果的に最少作業量最良用合いに落ち着きそうだ。設計方針迷いが一つ無くなったのも大きい

{希哲14年7月11日}{希哲14年3月}{誤操作}{用合い}{見触れ}{ダブルクリック}{デライト}{方式}{干渉}{向上}...=}(12)

{ダブルクリック方式 K#F85E/A-5B28-7726}

希哲14年7月11日,用語化。

見触れ単純化直感性向上のため,希哲13年7月31日5歩からデライト編集保存に使ってきた用合いだが,既存操作との干渉誤操作のしやすさが問題で,希哲14年3月から代替方式を模索していた。

希哲14年7月11日,様々な代替案を検討した結果,個人機ではCtrl キー併用することで概ね維持することにした。

{希哲14年1月15日の進捗時限}{希哲14年1月15日の進捗}{希哲14年1月15日}{丸添え字}{希哲14年1月5日13歩}{進捗記録}{進捗時限記録}{進捗時限}{map_}{C 修飾}...=}(14)

{希哲14年1月15日8歩 K#F85E/A-5B28-B9D9}

デライト最終調整KNEST 認証整理。

途中で終了。

map_ を利用している類型角添え字の仕様上 C 修飾がしにくいという問題があったため,丸添え字に C 修飾が可能なものを追加しようとして,すでに追加してあったことを思い出した。完全に忘れていたが,5日13歩でやっていたらしい。

早速これを利用している類型を修正し,C 修飾付きで参照出来るようにした。これで直感性が向上した。

=}
{理腑}{デライト正式離立}{構築函数}{希哲13年12月15日}{目標意識}{SQL 類型群}{希哲13年12月11日}{出場}{厳密性}{新知番実装}...=}(21)

{希哲13年12月11日の開発 K#F85E/A-5B28-815C}

出場周辺の理腑新知番実装換装続き。

かねてから検討していた SQL 類型群の導入実験を始めた。SQL を構成する諸要素を類型化し,各類型毎に構築子構築函数演算子を設定することで,DGDBI保守性を向上させる。

一日がかりで基本的な部分を書き換え終え,想像以上に直感性簡潔性厳密性が向上することが分かった。

大きな収穫ではあったが,デライト正式離立への目標意識が稀薄になってきたため,15日に目標を再設定した。

{直感性}
{}