{進捗記録}{Markdown}{部区}{希哲16年1月18日の開発}{希哲16年1月18日12歩}{行内埋め込み}{行内埋め込み記法}{書き分けられる}{視覚的な}{導入予定}...=}(161)

{希哲16年1月18日8歩 K#F85E/A-E74C-91F1}

進捗時限記録中略

埋め込み記法渡括記法)の応付子オプションなどについての検討終了

概ね方針が固まってきた

引数風の応付子

これまで埋め込み記法には,埋め込み方細かく指定するような機能がなく,例えば画像埋め込みでも表示サイズ水平方向寄せ方指定出来なかった。この問題当然当初から認識していたが,どうしてもごちゃごちゃしがちな部分なので,直感的美しい記法練るのに時間がかかった差し当たり欲しいのは画像埋め込み表示サイズ寄せ方指定出来る機能だが,他の埋め込み対象でも使える汎用的な枠組み整えておきたい

そこで,[寄せ方指定スペース]+([応付])[埋め込み対象]形式採用することにした。例えば,添付譜類PNG 画像100x100埋め込みたい場合,+(100x100)png書けるようにする。

丸括弧内は,函数引数風にコンマ区切りで,埋め込み対象毎に使える応付子設定する。引数名指定出来るように a=xa:x受け取ってもいいが,柔軟性必要なのであえて必須にはしない。スペースを含む文字列扱いたい場合考えられなくはないのでとりあえずコンマ区切りにしておくが,各引数扱い駒手欄感覚近い

他のとして,+100x100 png+100x100,png のように全てを引数的に扱うことも考えたが,あくまでも埋め込み対象とする応付役割まとまり一番分かりやすいという点で丸括弧採用する。また,埋め込み対象URL など長い文字列になることも多いため,応付+直後置く。あるいは,末尾に置く書き分けられるようにする。

水平方向寄せ方

水平方向寄せ方は,表組み記法採用予定スペースを使う方法応用することにした。以下のように,+ 前のスペース無しは無指定4つ未満は左寄せ4つ以上で中央寄せ6つ以上で右寄せとする予定

+png            <!-- 無指定 -->
  +png          <!-- 左寄せ -->
    +png        <!-- 中央寄せ -->
      +png      <!-- 右寄せ -->

直感性でいえば矢印のような記号導入することも考えられる。となるとまず <>使うことになるが,すでに多用しているため無闇役割広げる記号意味稀薄化しかねない。そうでなければ leftcenterright のようなキーワード導入するくらいしかないだろう。いずれにせよ,見た目的にもあまり美しくない

当初,以下のようにスペースの数表組み記法合わせようとした2つ中央寄せ3つ右寄せが,いくつか問題がある。

+png         <!-- 無指定 -->
 +png        <!-- 左寄せ -->
  +png       <!-- 中央寄せ -->
   +png      <!-- 右寄せ -->

まず,表組みにおけるセル内での編集に比べそこまで編集効率問題にならないためここまで短くする必要もなく,比較的長くなる後続文字列に対して目立ちにく過ぎる単純にスペース2つ中央寄せ3つ右寄せ表現には見えない

さらに致命的な問題は,いくつかの他記法との整合性だ。導入予定字下げ記法では,行頭全角スペース使う。あまり好き記法ではないが,Markdown4つの半角スペースを使う交度記法互換性のため導入する可能性がある。これらの記法混ぜ書いた場合,視覚的な整合性が取れない。

そこで,行頭に使う寄せ方指定スペース表組み記法とすることにした。交度記法にも使われる4つの半角スペース右寄せ一致するよりは中央寄せに一致した方が違和感がずっと小さい

行内埋め込み記法

おまけに,行内埋め込み記法についても少し考えた

これまで埋め込み記法部区として扱うことを主に考えてきたが,やはり行内埋め込み必要だろう。まだ草案段階だが,例えば以下のようにして画像回り込む段落が作れると便利だ。

++png++ 左上の画像に回り込む段落。
=}
{デラング}{進捗記録}{交度}{デライト}{`whr_kw()`}{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}...=}(70)

{希哲15年8月23日7歩 K#F85E/A-E74C-ECC6}

全知検索整備についての検討終了

全文検索にはとりあえず pg_bigm採用しておくことにした。知名検索でも中間一致検索性能課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse()組み込み函数として提供されるようになっているので問題ないだろう。

後縁実装どうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能実装したい。これに関しても,だいぶまとまってきた

カンマAND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難&AND で AND 検索,|OROR 検索対応することにした。除外検索条件次第- を使えるようにしてもいいだろう。

部分一致検索については,省略記号 ...ダッシュ記法応用した ---対応する。

描写検索については,基本的には昨年7月27日3歩方針踏襲し,末尾に ?? を加える形で対応することにした。デラングとの兼ね合い検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。

一つの可能性として,検索ボタンダブルクリックダブルクリック検索対象切り替える機能があってもいいかもしれない。

いずれにせよ,まずは既存の検索語変換交度whr_kw()まとめる作業から始めることになるだろう。

=}
{第四次宣伝攻勢}{『希哲日記』}{希哲15年7月15日}{希哲15年7月上旬}{室温調整}{無理せず}{考えさせられること}{状況の急激な変化}{微妙な蒸し暑さ}{希哲15年7月7日}...=}(29)

{希哲15年7月7日の日記 K#F85E/A-E74C-6639}

今日からバリバリ仕事を進めようと思ったものの,少しぼーっとしてしまう時間帯が多かった。

ここ数日,状況の急激な変化があったり,考えさせられることが多かったりするせいかもしれない。たまには必要なことでもあるので,無理せず仕事そこそこにして休むことにした。

蒸し暑い日が増えたこともありそうだ。冷房をつけるまでもないような微妙な蒸し暑さだったが,そろそろ意識的室温調整必要か。


少し頭の中ごちゃごちゃして目標意識も薄れてきているため,上旬中にデラング整備一段落させること,15日までに新生デライト宣言第四次宣伝攻勢開始を実現することを目安として意識し直す。

{あれ}{希哲15年4月26日のツイスト}{希哲15年4月26日}{Notion}{Scrapbox}{ごちゃごちゃ}{ツイスト}{美しい}{神経質}{感じる}...=}(13)
{人それぞれ}{希哲15年4月26日のツイスト}{希哲15年4月26日}{Notion}{ごちゃごちゃ}{ツイスト}{美しい}{好み}{綺麗}{徹案}...=}(11)
{進捗記録}{手定め}{輪括弧}{希哲15年4月13日の開発}{「コピーしました」}{「コピー済み」}{「コピー完了」}{写し取りボタン}{希哲15年4月13日の進捗時限}{希哲15年4月13日の進捗}...=}(37)

{希哲15年4月13日8歩 K#F85E/A-E74C-5CB3}

待っ読ボタン実装

写し取りボタンの追加・出振るい手定めを概ね完了。これをもって待っ読ボタン実装はいったん終了とする。

写し取りボタンには絵文字📋)を使うことにした。元々ごちゃごちゃしたボタンを置くための小窓なので,統一感が無くても問題ない,というのは発見だった。

これは共有ボタンにも応用出来そうだ。


写し取りボタン写し取りした時の表示「コピー完了」採用した。

輪括弧による写し取りでは「コピー済み」になっていたが,これはいま完了したというよりも時間的距離を感じさせる表現だった。かといって「コピーしました」はやや冗長な気がした。

「コピー済み」も,やや大袈裟な感じがする「コピー完了」とやや冗長な「コピーしました」の間を取ったものだった。ただ,その後の描き直しボタン完了ボタンで,慣れれば「完了」もそこまでくはないと感じていた。

ここで「コピー完了」に統一しておくことにした。修正済み

{新生デライト}{進捗記録}{領当て}{渡括記法}{希哲15年3月24日の開発}{盛り込める}{譜類選択ボタン}{追加要素}{思い付いた}{自動挿入}...=}(38)

{希哲15年3月24日5歩 K#F85E/A-E74C-035F}

譜類添付機能について検討して終了。

11日11歩である程度の方針は出来たが,用合いをどうするかが解決していなかった。

添付譜類が存在することを示すアイコンを置くにしても,現状の吹き描き見苦しくない領当てをするのは難しい。どうしてもごちゃごちゃしたものになってしまう。

そこで,渡括記法を使い,+[拡張子] の形式で描写自動挿入してしまうことを思い付いた描き直し時,描写に含まれていない譜類削除するようにしておく。この参照形式は元々考えていたことだが,こういう活用法があることは発見だった。

これなら用合い上の追加要素譜類選択ボタンのみで良く,実装半日もあれば十分だ。

これで新生デライト盛り込める

=}
{デラング}{平仮名}{進捗記録}{領当て}{デラング記法}{希哲15年3月23日の開発}{ややこしい}{見え方ボタン}{閉じるボタン}{最有力候補}...=}(72)

{希哲15年3月23日7歩 K#F85E/A-E74C-66D7}

デラング整備,「描き方ボタン」について仕様をまとめて終了。

デラング多機能化に伴い,学習宣伝等の観点から,他輪郭描写素文をもっと閲覧しやすくする必要が出てきた。

現状,Ctrl + ダブルクリックで閲覧することは出来るものの,ボタン自輪郭描き直しボタンのみ表示しているため,説明されなければどのように素文を見るのか初心者には分からない。

描き直しボタン追加時からしばらく全ての輪郭でそのまま表示していたが,紛らわしく,用合いもずっとごちゃごちゃしている時期だったため他輪郭では非表示にするようになった。

調整して復活させることは度々考えてきた。そのたび見送っていた大きな理由に,良い表現が見つからないということがあった。特にボタンラベル等に使う文言難しかった

簡潔かつ直感的ということで最有力候補は「覗く」だったが,漢字を使うと少し印象が硬い,平仮名で「のぞく」では「除く」と紛らわしい,語感もあまり良くない,そもそも何を覗くのか初見分かりやすいとも言えない,と一番マシな案が難点だらけだった。

今回の再考で,「描き方」が使えることに気付いた

描き直しボタンアイコン領当てはそのままに,ボタンラベルは「描き方」に変える。機能描写部Ctrl + ダブルクリックした時同様,描写欄のみ開く。

知名欄でも一部デラング記法を使えるようにする予定はあるが,利用頻度を考えると余計に感じることが多いだろう。従って,描写部が無い他輪郭では引き続き非表示とする。見る手段がないわけではないので困ることは少ないはずだ。

描き方ボタンで開いた場合,完了ボタンはもう少し自然に閉じるボタンにする。「見え方ボタン」にするのも面白いかと思ったが,かえってややこしいかもしれない。

「〜で描き直す」「〜で完了」から変えていなかった通注も「〜で描き方を見る」「〜で閉じる」とする。

=}
{デライト開発}{進捗記録}{デライト}{Firefox}{希哲15年3月15日の開発}{主力機の不具合}{ブックマーク通板}{挿し直し}{希哲15年3月15日の整清}{主力機清掃}...=}(36)

{希哲15年3月15日4歩 K#F85E/A-E74C-AA93}

作業場清掃主力機清掃続き。

の上から主力機内部まで全体的に埃取りをし,汚れていた表示機綺麗にし,記憶器スロットを変え挿し直した。

ついでに余計なものでごちゃごちゃしていた Firefoxブックマーク通板整理した。デライト筆頭に本当によく使うものだけに絞り込んだ。デライトFavicon竜胆蛍のままという問題もあったため favicons.sqlite を移動して再読み込みさせた。

これで視界が大分すっきりした。デライト開発に一層集中出来そうだ。

主力機の不具合については経過観察することにして,いったん終了。

{進捗記録}{iPhone}{Android}{希哲14年9月17日の開発}{希哲14年9月17日の進捗時限}{希哲14年9月17日の進捗}{希哲14年9月17日}{デライト用合い改良}{ダブルタップ}{進捗時限記録}...=}(17)
{ごちゃごちゃ}

{}