脳log[2011-04-23～]

最終更新: 2011-04-21T03:20+0900

♪ [SakuraEditor] Regarding: Request/359(CSV編集モード) - SakuraEditorWiki

TSVだったら、タブ幅が可変になればよさそう。列ごとにフィールドの最大幅より1文字分だけ右側にタブストップがくるようにすると表形式に整列される。ファイルを最後の行まで読んで調べないとレイアウトを決定できなくなるのがデメリット。レイアウト↔論理座標変換も工夫しないと遅くなる。この変換は検索などでやたら無駄に呼び出されるから速度低下は増幅される。CSVなら、カンマの幅を半角文字○個分扱いするのかな。一文字編集するたびに画面全体の再描画が発生するケースもあるけど気にならない程度？ 列を指定してソートできる秀丸さんかっこいい。タブストップを自由に設定できるというから、タブストップの位置を配列で持ってんのかな。タブ幅だけを覚えておいてその倍数がタブストップ、という現状にくらべると記憶領域も検索コストも必要になるけど、せいぜい人間が管理できる程度の数にしかならないだろうし。桁位置(64bits)×タブストップの数(10000)=80KBで十分過ぎるくらいか。

最終更新: 2011-07-30T13:35+0900

♪ [本] 言葉の選び方が合わない。

難癖をつけようとてぐすねを引いてるわけじゃないのに、1ページ目、2ページ目、3ページ目と下のようにつまずいてばかりでさっぱり話が進まない。

百人の町がありました。

町の人は、十人が大悪人で、三十人が善人のふりをした極悪人で、五十七人が自分のことを善人だと思い込んだ悪人で、三人が善人です。

善人の一人は、(省略)

もう一人の善人は、(省略)

最後の一人の善人は、最初から何もしませんでした。前の二人が失敗したのを見ていて、何をしても駄目なのだと思いました。彼は家の中に閉じこもって、人の声を聞かず、人の目から逃れて、ただただ町の未来を儚みました。

(省略)

悪行や善行はあっても、「悪人」や「善人」はどうだろう。悪行ばかりを行う人を悪人と呼んでみても、「善人のふりをした極悪人」や「自分のことを善人だと思い込んだ悪人」は何をもって悪人とされているのだろう。「最初から何もしませんでした」という「善人」を善人たらしめているものは何？ここで区別されているような種類の人間が存在しうる？ただの言葉遊びでなくディテールをもって。

1

エレベーターを出ると床がなかった。

遙か八百メートル足下の遠い区街は、しかし一立方センチメートル辺り指の数ほどの煤煙もカビ胞子もない大気を透してシャープネスを施され、異様なリアルさで陽平の眼底に不躾に飛び込んでくる。そこに住み暮らす六万五千の人間男性と八万超の人間以外の人いきれが服に髪に染みついてくるようにすら思えた。

「シャープネスを施」す。何が言いたいのかはわかる。「シャープネス」は画像のエッヂを強調してノイズを増すフィルタのことなんだろう。でも sharpnessは特定の価値方向性を持たない中立の単語だと思ってるので、結果がどちらに倒れるのか推測はできても理解したくない。

「リアル」。微粒子をほとんど含まず、建物の輪郭が強調されたようにはっきり見える澄んだ空気。この描写は「住み暮らす六万五千の人間男性と八万超の人間以外の人いきれが服に髪に染みついてくる」ようなリアルとは対立するように感じる。大気の存在を感じさせない景色は CGのような作り物臭さを喚起しそうだ。

口の端から頬にかけて指でなぞるような仕草をしてみせると、後輩は青ざめた顔を押さえていた手でようやく防臭マスクを顔にかけた。臭いだけでこの様では、もし遺体が収容済みでなかったら、この若者は入室早々に床を汚していただろう。

特定の場所を指示せず、たんに収容するというとき、自分は内へ取り込む動作をイメージする。だもんで、遺体が収容されている「から」悪臭+グロ映像のコンボを避けられて吐かずに済んだ、という部分で接続が順逆ひっくりかえってるような混乱を覚えた(その場所に収容されているからこそコンボを食らうんじゃないの？)。「収容」という一語のみを手がかりに何を言ってるんだと思われるかもしれないが、ここは話の冒頭なので二人のいる場所がモルグだという可能性だって残しながら状況の把握につとめていたわけだ。

最終更新: 2011-04-16T18:41+0900

♪

Firefox4. browser.overlink-delay を 70から 0へ。階層化されポップアップするサイトナビゲーションなどディレイを入れるべきところもあるがこれは違う。表示場所が決まってて邪魔にならないし、リンクに気付かないまま通り過ぎてしまわないように遅延なし。こういう設定があるはずであり、実際にあって、すぐに見つけて変更できるのが Firefoxのいいところ。

「なんで左半分しか使わない」の答え。「If your mouse cursor is on the left and the new line of text with URL would be covered with the cursor, then the URL is displayed on the right side of the content instead on the default left side.」右半分は URL表示の避難先として予約されていました。そういうレアケースのために長めの URLがいつでも省略されます。何が気に入らないって、省略されてることが一目でわからないのが良くない。右側にスペースが余ってみえるんだから。いっそ最下段のリンクの飛び先は表示されなくていいよ。見たければスクロールしたり貼り付けたりするから。その代わり下手な省略をやめて。

省略に関連して。googleに裏切られてはてブが応えてくれることに、省略されていないタイトルが title属性に設定されていることがある。...の先が非常にもやもやするの。ページ移動するかどうかはタイトルの全体を見て決めたい。でも googleでは見えない。見映えのために切り詰めて横幅をそろえるのはいいけど、その制約は title属性にはないから。実装上の制約があったとしても、そんなのは考慮しないから。

最終更新: 2011-04-16T21:35+0900

♪ [Ruby] 「HsbtDiary(2011-04-11) rubygems の taint と LOAD_PATH と $SAFE について」

前にこうならんかな？って書いたのをもう一度。

require 'hoge'

したときに hoge.rbなり hoge.soなりが taintedな $LOAD_PATH要素に基づいて発見されたときは SecurityError。見つからなければ taintedな要素はスルー。という動作を Rubyに期待したい。今は taintedな $LOAD_PATH要素を無造作に File.expand_pathして SecurityErrorが起こるに任せているんではなかったか。

 @2011-04-16 Ruby 1.9.2p136と 1.8.7p330で挙動が違うのが SecurityErrorへの疑問を増す。

1.9.2では(確かめたわけではないけど)汚染されたパスの展開がセキュリティエラーにつながってるから、汚染されたパスが $LOAD_PATHの末尾にあった場合は $SAFE=1の状況下で require 'cgi'が成功する。require '存在しないファイル'はセキュリティエラー。汚染されたパスを基に展開を試行したかどうかが分かれ目。

1.8.7では $SAFE=1の状況下で汚染された文字列を引数にした File.expand_pathは 1.9.2と違い成功するものの、上のような場合でも require 'cgi'に失敗する。これは requireが内部的に File.expand_pathを呼び出し――これは 1.9.2とは違いセキュリティエラーを起こさないけれど 1.9.2同様汚染された文字列を返す――、その汚染された戻り値を使った require_internal(仮名)が 1.9.2とは違い $SAFE=1のときにセキュリティエラーを起こしてるのだと思う。挙動からの推測。

一貫性が欲しかったね。できれば実用的なものが。特定のディレクトリ(汚染された$LOAD_PATH要素)に特定の .rb, .soファイル(requireされたファイル)があるかないか判った(SecurityError or not)ところでどうだというの。

最終更新: 2011-04-14T01:54+0900

♪ [SakuraEditor] BugReport/70 - SakuraEditorWiki

まったく、CViewCommander::Command_REPLACE_ALL ってのは人類の理解の範囲を超えている。

• 通常選択範囲を置換
• 矩形選択範囲を置換
• ファイル全体を置換
• 対象範囲を行単位で置換
• 対象範囲をひとつのマッチごとに置換
• 正規表現ライブラリを使って置換
• クリップボードのテキストに置換
• クリップボードの矩形テキストに置換
• 置換ではなく前に挿入する
• 置換ではなく後ろに挿入する

これ、あえて異なる複数の分類を一括りのリストにしてるけど、実際のコードがそうなのだ。こんな処理が一つの関数の中に、変数を共有しながら―しかも型を偽って本来とは違う使い方が特定の処理ルートではなされていたりする―、一部の処理を共有しながら、インターリーブされてる。

BugReport70.patch (1.7KiB, 2011-04-07 02:50)

submit(<commit以前)はしない。怖すぎる。

「「すべて置換」は置換の繰返し」フラグが ONのときの対策がまだ。

コミットログも読まずに軽率な修正。>BugReport70.rev2.patch (2.7KiB, 2007-04-07 06:50)

これから読む。>「SourceForge.net Repository - [sakura-editor] Revision 1049」, 「SourceForge.net: Sakura Editor: Detail: 1636751 - 行置換のオプション化＆問題修正」

うむ。削除したコードがなぜあえて論理座標だったのかわからない。

 @2011-04-11 「// 行単位で置換するので colDifは常に 0。」

って書いて削除したコードがパッチにあるけど、一つの行が複数のレイアウト行に分割されてることがある。一行処理して次の行……と思ったらまだ折り返された同じ行にいた、とか。前にも別件で書いてるけど、折り返しと矩形選択(+文字一括挿入／+置換)は本当にひどい組み合わせ。結果を予測できるものにするためには選択範囲の末尾の行から処理をしないといけない。そうすると文字の削除や挿入による折り返し位置の変化が後の処理に影響を与えないので。でもそうはなってない。だから、結果を維持する労力を割く必要もない「未定義」の動作だと考えてしまう。