こんにちは、SKK。
というわけでSKKを導入してみた。
Vi（非Vim）がどうにもだめで、Emacsばっかり使ってたころ、日本語入力といえばSKK。
kinputなんたらを導入してcannaに転向するまでのしばらくの間、skkで耐え忍んでました。
SKKの便利なところは、そのまま不便なところになるわけで、何といっても日本語能力が試されるのが低学歴には地獄の責め苦なわけです。
その他のimeがやってくれるところを人力でやろうというのですから、日本語能力に長けていれば、mozcはもちろんatokでさえ子供のおもちゃレベルで使えるわけです。
逆に、品詞を完璧に覚えてないと「▽おぼえて[登録:おぼえて]」といじめられることになります。この場合、shift-O,bo,shift-Eで、「え」で送ってやらないと、正しく変換されません。そもそも「おぼ」(漢字)「え」(送り)「て」(助詞)「ない」(助動詞)「と」(接続助詞)とか、日常生活で分けて考えながら話してないし・・・(「てん」の候補で出てビビった。中黒三連の起源はこいつか・・・？)。
文節区切りと送り位置を完璧に記憶している人にとって、SKKは最強。
SKKを学習オフで候補順を記憶すれば、ブラインドタッチ(タッチタイプに言い換えたほうじゃなくて、手元も画面も見ないで打つやつ)も意のまま。
凡百のimeで、ひたすらスペースバーを叩いて候補を呼んで、音だけ爆速、入力はそうでもない雑魚どもは道を空けろwですよ。
そうなるためには、形態素解析エンジンそのものにならなければならないわけで、だったら凡百のimeでいいや・・・。
で、ふりだしに戻る(ModoRu)毎度のこと・・・。
さよならSKK。また、そのうち。
neocompleteが俺より遅いとき。
新規で更で打つときは補完してくれたほうが圧倒的に早いのですが、写経をするときみたいに、ただひたすらにガンガン打っていくときには補完が邪魔になったりします。
neocompleteにはNeoCompleteToggleっていうのがあって、それを適当にmapして、止めたいときにはlock。
Toggleなので、Toggleになるようにvimrcとかに書く必要もなく、単にToggleを呼べばいい。
なんて便利。neocomplete。
どちらのご家庭にもある、おなじみの大漢和辞典ですが……。と、子供の頃は素で思ってました。
行く先々の本棚に大漢和辞典が鎮座してるのがわりと普通で、限界集落の分校ギリギリ（分校から団塊前後で人数が増えて一時的に本校化していたけど後に廃校）の小学校（校歌はもちろん諸橋轍次作詞）の狭い図書室にもありました。
毎年、年賀状と暑中見舞いが来るどっかのじいちゃんだと思っていた止軒さんが、諸橋轍次先生。
元庄屋様の子供だったにしても、あの限界集落からよくもまああそこまでたどり着けたもので、尊敬とかいうレベルを遥かに超えた謎仕様です。
三条の街に出るまでに、今のスノーピークのあたりで一泊しようかという時代に、何をどうやったらああなれるのか。
プロフィールはググれば出てくるレベルでしか知りません。10歳くらい下のはずのじいちゃんがなんで友達だったのかもよくわからん。
当時を知ってる人もみなさん鬼籍。
生きてるうちに聞いときゃよかったと思っても、生きてるうちは聞こうとも思わなかった。もったいないことで…。
MacVimはiconvで文字コードを変換しているので、mac japaneseはどうにもならない。
iconv -lに出てくるコードには載ってない…。
CP932前提で変換すると♡とか丸数字とかが出てきたところで終了。JIS2004前提で変換すると、そこらへんが文字化け。iconvを使っているので当然ですが、MacVimで++encしても同じ結果。まともに変換できるコマンドラインツールはnkfくらい。nkfすごい。
Indesignがmac japanese(Shift_jis 83pv)以外でも一応読み込める（テキスト取り込みのときに、オプションで、読み込みオプションを表示にすると、画像とかと同じように読み込みのオプションが出くる。これを知らない人がいたりする）ようになってからも、いまだに推奨はShift JIS 83pvのまま。デフォルト値も同じで、一般的なワープロソフトとかテキストエディタみたいに、指定文字セットでのプレビューも出ない謎仕様を続けているので、印刷業者さんも、mac japaneseを前提にしたこまごました仕組みを使い続けていたりする。
そのため、推奨文字コードは未だにmac japaneseなんで、わざわざmac japaneseで保存して送られてくるテキストがほとんど（ありがとうライターさん）。
コピペだと、クリップボードかなんかが適当な手段でなんとかしてくれるようで、画面に表示されている形でそのままコピペできる。
どうにでもなるMacVimで使うためには形を保ったままutf-8に変換しないといけないので、nkfは手放せません。
べ、べつにcot editorとかmi（えむあい）とかで変換してもいいんだからね…。っていうか、そのままそれで行け。なんですけど、nkfでmac japaneseからutf-8に決め打ちで変換するドロップレットを作ったからそっちのが速いし…。おれMacVimmerだし…。emacsどこいった…。
mediaxさんから司馬遼太郎全小説徹底ガイドというのが出ています。
面白いのは置いておいて、その作業中のこと。
表紙を見ての通り、しばりょうたろう先生の「りょう」は二点しんにょうで、司馬 遼 太郎なわけです。
普通に変換したら、一点しんにょうで出てきますが、正しい文字で表示されているソフトからファイル名にコピペすると、二点しんにょうの正しい表記のファイル名になるわけです。
これを、OSXサーバにコピーすると、普通にコピーできてしまいます。これをクライアント側から操作しようとすると
Mac(Finder, AFP) 何事もなくコピー、移動、削除可能。
Mac(Finder, SMB) 見えない。目を凝らしても見えない。
Win(Exproler) 見えてるのに、コピーも削除もできない。
Linux(thunar,SMB) 見えない。まぶしくて見えない。
OSXのFinderからSMBで接続すると、コピーもできませんし、司馬遼太郎_001.jpgと司馬遼太郎_002.jpgの区別もできないらしく、コピーできないくせに「司馬遼太郎_001.jpg」があるディレクトリに「司馬遼太郎_002.jpg」をコピーしようとすると「司馬遼太郎_002.jpg」はすでに有ります系の警告が出て、置き換えるをクリックするとエラーで終了。
同じディレクトリにFilezillaでFTPでアクセスすれば、どの環境からでも普通に操作できます。
ftpサーバはファイル名の文字コードは特に何もせず、クライアント任せにしてあるので、クライアントがSJISだと思えばSJIS, utf-8だと思えばutf-8なので、クライアント側がなんか適当な手段でどうにかしてるんでしょうが、Netatalk&Sambaサーバで試しても同じなので、smbのサーバ側がなんかしてるのかな。
Windowsサーバがないので試せませんが、windowsサーバだとどう動くんだろ。
