Days on the Moon

Windows の操作全般および MS-IME で Emacs のようなキーバインディングを利用するための個人的なメモ。

Ctrl キーの位置調整

Change Key を利用。管理者として実行する。

• CapsLock → Ctrl (左)
• カタカナ/ひらがな → Shift (右)
• 半角/全角 → Esc

XKeymacs の設定

XKeymacs のスナップショットバージョンを利用。Explorer を「管理者として実行」し、その上で C:\Program Files にフォルダをコピー。

dot.xkeymacs

以下の内容でファイル %APPDATA%\dot.xkeymacs (たいていは C:\Users\{user}\AppData\Roaming\dot.xkeymacs) を作成。

(fset 'browser-back [browser-back])
(fset 'browser-forward [browser-forward])
(fset 'find-next [f3])
(fset 'find-previous [?\S-f3])

プロパティの「基本」タブ

• 「アクティブウィンドウから離れる」の C-z 及び M-F12 を無効化
  • C-z は素通しさせ、「元に戻す」として扱う。
• 「消去、編集」の C-t 及び C-x C-t を無効化
  • C-t は screen でのメタキーとしてのみ用い、他の用途には使わない。
• 「その他」の Esc 及び C-[ を無効化
  • メタキーには Alt のみ用い、Esc は Esc としてのみ用いる。
• 「IME の切替え」の全項目を無効化
  • IME のオン / オフは変換 / 無変換キーで行う。
• 「その他」の C-x h を無効化
• 「移動」の C-l、「消去、編集」の C-k、「その他」の C-u を無効化
  • MS-IME に対して「XKeymacs を無効にする」としていても、Firefox など (IME で入力中の文字列を自前で描画するアプリケーション?) では MS-IME での入力中に XKeymacs の設定が適用されてしまうので、MS-IME のキー設定と干渉するものは無効化しておく。
• 「その他」の C-0 ... C-9 を無効化
  • 誤爆しかしない。必要なコマンドの数を事前に算出し、正しい数値のキーを打つのは私には困難。

プロパティの「詳細」タブ

• 「その他」の Esc に Ctrl + [ を割り当て
  • C-[ は Meta ではなく単なる Esc として用いる。
• 「その他」の Temporarily Disable XKeymacs に Ctrl + ; を割り当て
  • C-; C-○ と打つことでネイティブのショートカットキーを利用できる。";" (セミコロン) はホームポジションなので打つのも簡単。
• 「その他」の Select All に Ctrl + X H を割り当て
  • Firefox Nightly で C-x h が期待通り動作しないので、これをネイティブの「すべて選択」に置換する
• 「その他」の newline に Ctrl + J を割り当て
• 「オリジナルコマンド」の browser-back に Meta + , を、browser-forward に Meta + . を、find-next に Ctrl + . を、find-previous に Ctrl + , をそれぞれ割り当て
  • "," (カンマ) は "<" (小なり) すなわち「←」(戻る方向) を、"." (ピリオド) は ">" (大なり) すなわち「→」(進む方向) を、それぞれ表す。

MS-IME の設定

• 「スペースの入力」を「常に半角」
• 「Shift キー単独で英数モードに切り替える」を有効化
• 英数字及び記号類を「常に半角に変換」、ただし「～」のみ「変換しない」

MS-IME のキー設定

インポート / エクスポート機能がなさそうなので、ひとつずつ設定しなおしている。

Ctrl + H/K/L/M/O/T/Y/Z は変更なし。

MS-IME のキー設定の「機能選択」には「-」という項目がふたつ存在するが、先頭のものは MS-IME を利用しているアプリケーション側にそのキーを伝え、末尾のものは MS-IME 内でそのキーを握りつぶす。

こんにちは、はてなでアプリケーションエンジニアをしている nanto_vi です。この記事は Hatena::Staff Advent Calendar 2011 の一環として書いています。Advent Calendar の会場ははてなブログとなっていますが、主催の antipop さんに尋ねたところ何でもよいというような返答があったのでここで書きます。

はじめに謝っておきますが、この記事ははてなとほとんど関係がありません。タイトルに「はてな」と入っているのは Advent Calendar の要件を満たすための目くらましあり、内容はといえばはてなのノウハウでもなんでもない、私が最近個人的に心がけていることです。ごめんなさい。

できれば明示的に

業務で書くコードは複数人により読み書きされメンテナンスされるので、わかりやすさが重要になってきます。わかりやすさを保つためには暗黙的に行われる操作を減らし、明示的にコードに表した方がよいと感じます。たとえば、Perl では、

use Encode;

# encode_utf8 関数は Encode モジュールで定義されている
my $octets = encode_utf8 $string;

のようにモジュール読み込み時に自動的に関数をインポートすることができますが、それよりも、

use Encode qw/encode_utf8/;

my $octets = encode_utf8 $string;

のようにインポートする関数を明示的に指定したほうが、その関数がどこで定義されているのかわかりやすいでしょう。

個人的には、関数や変数の名前で grep をかけてその定義(外部で定義されている場合は宣言)を探し出せることが、「明示的」であるための最低線ではないかと思います。

入力には正規化を、出力には符号化を

アプリケーションを作るうえで入出力の扱いは避けて通れません。入力元はユーザーだったりバッチ処理スクリプトの引数だったり、出力先はユーザーだったりデータベースサーバーだったりしますが、いずれにおいても入力には正規化処理を、出力には符号化処理を、それぞれ施すことになります。

正規化は一般に不可逆です。空白文字類をすべてスペースに置換した後はもともとスペース以外の空白文字が含まれていたのかわかりませんし、数値「42」を生み出した入力は "42" でも "42.0" でも、はたまた "0x2A" でもありえます。

符号化は一般に可逆です。あるデータをユーザーのもとへ送り届けるのに、そのデータを HTML のテキストとして扱えるよう一部文字を文字参照の形に符号化し、その HTML ソース全体を文字符号化方式 UTF-8 をもって符号化し、さらには HTTP メッセージに、TCP のセッションに、IP のパケットにと符号化を重ねていきますが、それらすべては符号化規則を逆に適用することで元の形式へ復元できます。

たとえば HTML として解析され、その結果が JavaScript の文字列として、HTML として、URI としてと順に解析されるデータを Template-Toolkit で出力する場合、解析の逆順でそれぞの形式に応じた符号化を施す必要があります。

<script type="text/javascript">
document.write('<a href="/search?q=[% word | uri | html | js %]">検索<\/a>');
</script>

script 要素の内容は CDATA 型であり文字参照は解決されないので、最後に html フィルタをかけることはしません。また、そもそもこのような多重にフィルタをかける事態は避けたほうが賢明でしょう。

入出力いずれにおいても、データがどういう形式で扱われるのかを意識し、それに応じた正規化処理または符号化処理を施すことで、意図しない入力が致命的な挙動を引き起こすこともある程度は防げるのではないかと考えます。

次は hitode909 さんです。