甥っ子が具合が悪く正月から入院という事態なので、姪を預かることにする。
天真爛漫、元気溌剌な姪と、甘やかされ放題の末っ子は相性が悪く、泣かされてばかりいる。 年齢は倍違うのにな。
姪を連れて、安来の叔母の家により、それから米子の実家に。それぞれ正月の挨拶。
夕方には帰る。渋滞を避けようとして、道を間違え伯太町の方に向かってしまう。 が、予期せず白鳥を眺められたりして。
姪はそのまま泊まる。
PC関係のメモに、
Matzにっき で使われてるのはカスタマイズされてるみたい。
と指摘される。そうそう、カスタマイズした時点で満足してしまって、公開してなかったな。
あおきさんのところの最新らしい1.41とマージして、 ここに置く。
主な変更点は
くらいかな。
あと、tdiary.rbのapply_pluginメソッドの正規表現を
r.gsub!(/<.*?>/, '') if remove_tag
から
r.gsub!(/<.*?>/m, '') if remove_tag
に変更(mフラグを追加)しないとfnプラグインがうまく展開できない。
弟を連れて親戚のうちに。妹夫婦も来ていて大変な人数に。
陽気なおじさんと話し込んでいた。70代、80代の人々にとって、 戦前とか天皇制とか戦争とかは遠い話ではないことを実感した。 知らない話がたくさん聞けて興味深かった。
その後、米子へ。松江より米子の方が人口はよっぽど少ないのに買い物するところは多いのは不思議だ。 「本の学校」による。お世話になった書店(の支店)である。 本屋としての規模では最近うちの近所にできたセンター店(多和山店)に負けるが、 こっちの方が変わった本がたくさん置いている。
何冊か買い物した後、鳥取に帰る弟を米子駅まで送り届ける。
妻の実家にあるデジタル体重計のユーザインタフェースが秀逸だ。
従来のアナログ型体重計の操作ステップ(おおげさな)は以下のようになるだろう。
単純だ。しかし、たまに原点(負荷がかかっていない状態でのゼロ点)がずれていたりして不正確なことがあるので、 時々針の位置を調整する必要があるし、目盛りが動いたりして、 正確な数値を知ることが難しいときがあってストレスがたまる(ような気がする)。
一方、私の家にあるような通常のデジタル型体重計の操作は以下の通り。
まあ、普通だ。操作ステップがやや増えているので実際は面倒になっているのだが、 これが「より正確(そう)な数値」、「原点調整不要」というメリットとどう折り合うかの問題だろう。 本当にアナログ体重計より正確かどうかは実際よくわからないけどね。 あっちは針の位置で、なんとなくより細かい情報を示しているわけだし。
ユーザインタフェースの話に戻ろう。
これに対して妻の実家にある体重計の操作ステップはこうだ。
すばらしい。アナログ体重計に負けないくらい単純になっている。 「原点調整を後で行う」という発想はコロンブスの卵のようだ。
眼鏡利用者としては、降りてから顔を近づけて数値が読めるのも助かる。 体重計に乗る時は眼鏡を外していることも多いので。
手元のcalkiがUTF-8の「》」相当の文字(U+8BB)を含むエントリが文字化けするので、 nkf-utf8のソースを見てみた。 どうも自動判定の優先順位がEUC-JP,SJIS,JIS,UTF-8で固定されていて、 EUCの範囲内に収まる文字列はすべてEUC-JPとみなすことになっている。 で、UTF-8の「》」はEUC-JPの「損」と同じバイト列なのだ。
どうしたものかなあ。入力の文字コードははっきり分からないので ある種の判別と変換は避けられないしなあ。
今後、M17Nを取り込むにあたって もっと賢い自動判別がは必要だろうなあ。自動判別は正しくない判断をする 可能性があるから、なるたけ避けたいと言っても、実用のためには 避けて通れないだろう。
優秀なコード判別アルゴリズムはあるのかな。 Emacsのコード判別は結構賢いな。 上記の「》」と「損」も区別できてるし。