もひとつvimネタ

vimのデフォルト文字コードはcp932で使っているわけだが。

まあ、それはそれで全然問題ない(他の文字コードは変換して読み込んでくれるし、cp932のファイルは「:set fenc=UTF-8(UTF-8の場合)」すればいい)。

とはいえ、悲しいかなWindows上だけで作業が完結すればいいのだけれど、MacOSがあったりすると、そちらではUTF-8で使いたい。

だもんだから.vimrcは、

if has('win32')
  set hogehoge
endif

とか、

if has('mac')
  set fugafuga
endif

なんてのが散在していて、ちょっと(というかかなり)見苦しいことになっている。にもかかわらず、文字コードだけはどっちもcp932なので、それ関係はきれいなもんです。

が、やっぱり、MacOSではUTF-8デフォルトにしたい。

というわけで、久しぶりに2ちゃんねるに行ったら、あるもんですね。解決策が。

とりあえず、全面的にvimで使用する文字コードをUTF-8にするには、KaoriYa版では.vimrcに、

source $VIMRUNTIME/encode_japan.vim

しといて、「encode_japan.vim」の下から3行目にある、

set encoding=japan

を、

set encoding=UTF-8

にすればいいらしい。

ということは、得意の「if has('mac')」を使って、環境ごとにUTF-8とcp932を使い分けることができるということになる。

いいじゃないすか。帰ったらさっそくやってみることにしよう。

ニッチなスクリプトだなあ

おぉ、こんなものがあったとは。

まあ、実際に導入して使うかどうかは微妙だけど。

エラーコード:E513を克服する

去年の8月16日(日本では17日)にここで「E513エラー」が出るよー、と泣いていたわけですが、その後いろいろ調べて止めることに成功していたのですが、その件を書かずに放っておいたら検索している方が(かなりの数)いるようなので、ここでまとめておきます。

  • 症状

vim使用時に、起動後、

:set enc=utf-8

などとして、バッファに対する漢字コードを設定しようとする、あるいは、

:set fenc=euc-jisx0213

などとして、ファイルに対する漢字コードを設定しようとすると、

 E513: write error, conversion failed (make 'fenc' empty to override) 

というエラーが表示される。

  • 原因

起動直後のvimに漢字コードが設定されていないため、設定されていない値(エンコード値)から他の値(エンコード値)へのコンバートに失敗し、エラー表示となる。

バッファが持っている漢字コードは初期時に明示的に保持されている必要がある。

これはつまり、

vimを普通に(漢字コードの変換を考えずに)使用する場合は、たとえばWindows日本語環境で使用する際は、CP932として文字を表示し、そのままテキストファイルとして保存するので、無問題(オプションの“encoding”はWindowsから取得できる情報を元に自動的に設定される)なのだが、漢字コードを変換する場合はiconvを使用するため、どうしても、「どのコードページ(≒漢字コード)で起動した」かという情報が必要になる。

ということ(かどうかは、正直アヤシイ)。

  • 対処

これまでiconvを使って漢字コードを変換していたが(ていうか、vim7のいまもiconvを使っているわけですが)、その際、以下のような設定を%HOME%の.vimrcに書くことを推奨されていたと思う。

" 日本語を扱うために必要
set encoding=japan

" ファイルの漢字コード自動判別のために必要。(要iconv)
if has('iconv')
  set fileencodings&
  set fileencodings+=ucs-2le,ucs-2
  let s:enc_euc = 'euc-jp'
  let s:enc_jis = 'iso-2022-jp'
  iconvがJISX0213に対応しているかをチェック
  if iconv("\x87\x64\x87\x6a", 'cp932', 'euc-jisx0213') ==# "\xad\xc5\xad\xcb"
    let s:enc_euc = 'euc-jisx0213,euc-jp'
    let s:enc_jis = 'iso-2022-jp-3'
  endif
  fileencodingsを構築
  let &fileencodings = &fileencodings.','.s:enc_jis.',utf-8'
  if &encoding =~# '^euc-\%(jp\|jisx0213\)$'
    set fileencodings+=cp932
    let &encoding = s:enc_euc
  else
    let &fileencodings = &fileencodings.','.s:enc_euc
  endif
  定数を処分
  unlet s:enc_euc
  unlet s:enc_jis
endif

しかし、(おれの把握している限りでは)vim7以降のアーカイブにデフォルト(というか見本)として同梱されている.vimrcファイルには、「日本語対応のための設定:」として

source $VIMRUNTIME/encode_japan.vim

という一行があり、この「encode_japan.vim」ファイルを見ると、先の「ファイルの漢字コード自動判別のために必要。(要iconv)」と同じ内容になっていることがわかる。

そこで、先の「" 日本語を扱うために必要」から「endif」までの全25行(空行含まず)をコメントアウト(もしくは削除)する。

これで、vimは正しく漢字コード設定値の取得先を認識することができ、以後「:set enc=iso-2022-jp」しても「:set fenc=utf-8」してもE513を表示しなくなる(ハズ。少なくともおれのvimは想定どおりの動作をするようになった)。

vim7.1のナゾ

これまでvim7.1.169を使っていたのだけれど、ちょっと挙動がヘンになった。

なんかやらかしたはずなんだけど、なにをやったせいで挙動がヘンになったかわからないところが悲しい。もしかするとtwitter postプラグインのせいかも、とか思わないではないけれど、んんん。。。

どんなふうに挙動がヘンかというと、通常文章(日本語)を書く際に、textwidthは「0」にしているのですね。わたくし。これをftpluginのtext.vimに、

setlocal textwidth=0

として制御しているわけです。まあ、.vimrcに書いちゃってもいいんだけど、なんかこの類のパラメータはftpluginのsetlocalで制御するのがいいんだろうな、とか考えているので。

ところが、これが効かなくなっちまったんだよなあ。「set all」して見てみると、「textwidth=78」とかになっちゃってる。どこで設定しちゃってるんだろうか(あるいはどこの設定が影響しているのだろうか)。

とりあえず、最新バージョンの7.1.196にしてみたんだけど、変化ナシ。いよいよアタマを抱える。

[解決]

$VIMと$VIMRUNTIMEを「grep textwidth *.vim」して、どうも「vimrc_example.vim」が悪さをしているらしいと推測。これは作者であるBramさんが提供してくれているvim設定例なんだけど、香り屋版はわざわざこれを読み込ませるスクリプトを初期.vimrcに書いてくれているのです。

このBram設定はほとんどアタクシには役に立たないので、読み込みファンクション直前に、

let g:no_vimrc_example=1

として、無効化しているのだけれど、今、見てみたらその一行が消えていた。とりあえず復活させて終了。これにて一見落着。……なんだけど、もしかして、おれの.vimrcは誰かに改竄されてたりするのだろうか。それはセキュリティ的にどうなんだ。一件落着どころの話ではないではないかないではないか。

vimスクリプトで苦戦した件

仕事してる最中にエディタから思いついたことだの愚痴だの呪いの台詞だのをポイポイ投げ入れられたら便利じゃね? そらー便利だ。やるべやるべ。

というわけで、vimから「:TW」と入力すると小窓(バッファ)が開き、そこに文章を入力して改行したら(いまさらながら)twitterにポスト、なんてスクリプトを書くことにしたのが数週間前。

とりあえず、vim.orgのスクリプトを検索したら、似たようなプラグインスクリプトはあったんだけど、Pythonのライブラリを使うなど、あまりシンプルじゃない。マクロ自体はシンプルなんだけどね。

希望としては、curl(でもwgetでもいいんだけど)を使って、新しくナニカを導入せずに、スクリプトだけで制御したいこと。そうすると、Macでもシアワセになれるし。

なにはともあれ、twitterのAPIを調べてみると、たとえばcurlを使う場合、単に、

curl -u USERNAME:PASSWORD -d status="ほげほげ" \
     http://twitter.com/statuses/update.json

とすればいいだけ。

問題はアップしたいテキストの「ほげほげ」はUTF-8でURLエンコードしなければならない点。

JavaScriptでいうところの「charCodeAt()」をvimは持っていないので(まあ、ほかにもいろいろ持ってないけど)、この部分は実装しなければならない。もっとも、マルチバイト対応のvimであれば、UTF-8への変換はICONVを使って処理できるので、

execute 5 . new
setlocal enc=utf-8

として、文字コードにUTF-8を指定した5行分の窓(バッファ)を開け、入力した文字をエンコードすることにした。カンタンそうでしょ?

ところが、「getline(".")」で取得した文字コードはUTF-8ではなく、CP932として認識されてしまう。

たとえば「の」の場合、期待されるコードは「%E3%81%AE」なのだが、「%30%6E」が返ってくる。CP932でエンコードした文字列はtwitterは解釈してくれないので、当然、twitter上にはなにも表示してくれない。アクセスされてなにかがポストされたことは残るみたいだけど。

UTF-8になってないんじゃないかと考えて、エンコード関数のプロトタイプで「echo」してみると、ちゃんと「%E3%81%AE」と示される。つまり文字コードはあってる。

どうも小窓(バッファ)を開けたスクリプト本体に書いたエンコード関数からは、扱う文字データはすべてCP932として処理されているっぽい。なんのための「set enc=utf-8」やねんという話もあるのだけれど、「:wq」したファイルはUTF-8で保存されているので、そういう仕様なのだろう。

というわけで、小窓(バッファ)を開けるためにスクリプトを呼び出し、ポストするためにさらにスクリプトを呼び出すという、なんかもう非常にウザイ処理となっていて、お気軽にエディタから呪詛のコトバをtwitterに放り込むという当初の目標からはかなり遠いところに着地したわけです。くやしいー。きー。

もう少しブラッシュアップしたら(しないと思うけど)公開しようかとか考えてみたりみなかったり。

もっとも、Webアプリケーションを含む、別アプリケーションを立ち上げてログインして入力して……、なんてことからすると、大変気楽ではありますが。

エディタもおかしくなる

ファイルタイプを判断して走るvimのマクロ(というかプラグイン)が想定どおりに動かずイライラしていたわけだが。とりあえず、最新版(香り屋の8月15日版)に差し替えたところ、動作が元に戻り安堵する。

こういうとき、ネックとなっている部分の切り分けができないので、とても悲しい。したがって、ファイルのエンコードを変更すべく、

set: fenc=euc-jisx0213

として、「:w」すると、

E513: write error, conversion failed (make 'fenc' empty to override)

などと怒られてしまうわけだが、おれにはいかんともしがたかったりするのであった。「make fenc empty to override」言われてもねえ。

ちなみに、「fenc=utf-8」とか「fenc=cp932」は効くんだよね。ということは、“euc-jisx0213”という引数が間違っているのかな? でも、前の前の前の前の……バージョンでは効いていたんだよなあ。

索引の呪いが降りかかっている件

「インデックスを作るのがめんどくせー」と某氏に伝えたところ、

(global-set-key "z"
   (function (lambda nil (interactive)
             (save-excursion
             (when (< (point) (mark)) (exchange-point-and-mark))
             (copy-region-as-kill (mark) (point))
             (insert "\\index{") (yank) (insert "}")))))

をevalしてからマウスでリージョン指定して、「z」を入力すればサクサクだYO。などと言われる。おれがいつemacsに宗旨替えをしたというのだ。

tex.vimには、すでに、

vmap <buffer> zInd <ESC>`>a}<ESC>`<i\index{<ESC>

としてあるのであって、つまりそーゆうことで“めんどくせー”ワケではないのだよ明智くん。などと独りごちる。

iminsertの設定値が変わる件

よくわからないので、外している可能性が非常に高いのだが、VistaとXPではiminsertの動作が違うくね?

.vimrcや.gvimrcに、

set iminsert=1

とかしておいても、Vista上でvimを起動するとiminsert=2になる。XPではiminsert=1。

これはVistaの問題か?

vim 7のインテリセンス(ウソ)について

vim 7では補完候補はウィンドウに一覧として表示するようになったわけだが、デフォルトのcolorschemeだとバックがピンク(!?)で文字が黒、選択行はグレーという、「お前、大丈夫か?」というような配色なので、[ctrl]+[x]-[ctrl]+[k]を押すたびに気が狂いそうになっていたのだが、これを制御しているのがどこかわからない。

いろいろ手を尽くして、どうもPmenu*を設定すればいいらしいということはわかったものの、.vimrcに書いても.gvimrcに書いても反応がない。

泣きながら2ちゃんねるの猛者に訊いてみたらあっけなく解決した。

(ファイルタイプでの判別ではなく)vimそのものの配色定義になるのだから、colorschemeファイルに書き込まなければならない。

また、scriptnamesで確認するとわかるように、colorschemeファイルは最後の最後に読み込まれるので、.vimrcや.gvimrcに書いてもすべてクリアされてしまう。

そのため、もし.vimrcに直書きするのであれば、

:colorscheme hoge
:hi Pmenu ……

とする(これはうまくいかなかったような希ガス)。

一方、colorschemeでvimの配色を変更したあとに実行するために、autocmdを使用する手もある。

:autocmd Colorscheme * hi Pmenu ……

あたくしが採用したのは、すでにオリジナルのcolorschemeを使用していたこともあるので、こちらに記述する方法。中身はこんな感じ。

hi Pmenu guifg=black guibg=lightgray 
hi PmenuSel guifg=yellow guibg=darkblue 
hi PmenuSbar guifg=black
hi PmenuThumb guifg=darkblue

これでとりあえず、上記のような表示スタイルとなった。飽きたらまた色味は変えるけど、忘れないようにとりあえず。

vim 7が惜しい件(1)

大喜びでvim 7を使用しているのだが、たとえば、

:e //volvic/water/documents/hoge.txt

などとして、ネットワーク越しにhoge.txtを編集する場合、対象ファイルがSHIFT-JISであれば問題なく開くのだが、UTF-8だったりすると文字化けする。

ローカルに置いてあるファイルを右クリックしてvim 7で「開く」した場合は、文字コードに関係なく(コンバートして)開くことができるので、おそらくネットワーク越しの編集でのみ発生する不具合っぽい。

ちなみにvim 6.4.6では普通にオープンできるので、これはvim 7特有のバグだろう。

デイリービルド版だから、まあしょうがないんだけどね。これ、早めに直してくれるとうれしいなあ。

などということを、こんな場末のサイトにちまちま書くのではなく、とっととバグレポートを送れということなのであった。

vimのバージョンが上がっている件

ご存知のとおり、おれはvimユーザーで、OSを再インストールした際は、なにはともあれgVimのディレクトリを作るのはもちろん、手前のプラグインだのシンタックスファイルを山のように(やや大げさ)突っ込んであるvimfilesを%USERPROFILE%に、.vimrcと.gvimrcとともに放り込まなければ、先に進めないわけだ。

で、メジャーバージョンアップしたvimがリリースされているわけだが、タブ機能とかdiffが自前のエンジンで動いたりという話を聞くだけ(Webベースなので正確には「読むだけ」ですね)では、あまり触手が動かなかった。愛用している香り屋のvimもデイリービルドだったりするし。

というわけで、様子見を決め込んでいたわけですけど、補完機能をビデオにして紹介されている方がいらっしゃいまして、それを見たら、俄然、バージョンアップしたくなりました。

とりあえず、その動画を見よ!

なんかもう、VS並みでしょ? 上も下もナニカが表示されるため、肝心のメインペインがガクガクして使いにくそうだけど;-)。

もともと、dictファイルをフル活用することで補完っぽいことをしていたわけだけど、ここまでやってくれるのなら、バージョンアップしてもいいかなとか思う。動画はLinux上でPythonコードをいじっていて、あとはHTMLとかCSSとかXMLくらいしか対応してないようなのだけれど、おそらく普通のテキストファイルにキーワードを記述していけば、好みの言語に対応する(ハズ)。ということはC#でもVBでも、これまでのdictファイルを再構成すればいいのではないか。なんてことを漠然と考えたり。

WManagerを使って3ペイン状態にし、補完バリバリでコードが書けるなら、GUIを伴わない軽いEXEがわらわら作れる(ような気がする)。

というわけで、香り屋のvim7デイリービルドを落としてきたわけでございます。

お楽しみはこれからだ!

転職/就職の季節

But things are going to change. I have accepted a job offer and will go back to a full time job in a few months. To avoid speculation and rumours: I am going to work for Google in Zurich.
Vim sponsorship changes

vimを作っているBram Moolenaarさんも、ついにGoogle Zurichに職を得たようで。いろいろ感慨深いなあ。

正確さを求めると大変なことになる件

ここでネタにしたvimのTips募集の件だが、ウワサのvoidさんがすごい勢いでレスポンスを返していて大変なこと(そうでもない)になっていて、うっすらウケる。

voidさんの言うことには一理あるのだから、このレスポンスによって原稿がどう変わるか注目したい。

でもなあ、「流用などする時にはご一報ください」という首謀者の一文にはすごい違和感を覚える。vimの基本操作だよ? 「そのまま転記/転載する場合はご一報ください」の間違いじゃないかと思われるのだが、どんなもんでしょうね。

Tipsを集めることに関して

ソフトウェアではじまってデザインで終わる某月刊誌の記事のために、某SNSでvi/gvimのTips執筆者を募集していたけど、それこそhttp://del.icio.us/tag/vimとかhttp://del.icio.us/tag/gvimを底引き網で漁ればすさまじい量のTipsがもってこられると思うんだけどな。

まあ、それを記事化するのは大変だろうけど。

ちなみに以下のサイトのTipsはなかなかよかった。

VS.NET2003をvi/vimモードにするアドイン

わはは。

まあ、とりあえずメモ。しかし世の中には酔狂な御仁がいるものだなあ。

ViEmu is a an add-in to Visual Studio which enables vi/vim-like editing for Microsoft Visual Studio .NET 2003.

viemu doc
  • viemu=http://www.ngedit.com/viemu_doc.html

vimの置換にはまっていた件について

vimで「<」を「&lt;」に、「>」を「&gt;」に置換しようと思って「%s/>/&gt;/g」なんてやると、大変なことになってしまっていたわけだが、普通に「%s/>/\&gt;/g」で目的が達成できることに、先ほど気がついた。なんでメタ文字を忘れているかね。

ちなみに「%s/>/&gt;/g」と、メタ文字で「&」をエスケープせずに置換した場合、「&」に置換したい文字(この場合は「>」)が展開されるため、結果として「>gt;」となる。ということは、文書中の全「常盤」に「貴子」をつけたいときは「%s/常盤/&貴子/g」でいいわけだ。なるほど。

ネタ

こりゃおもしろい。

日本viユーザ会設立の件

なんてのが9月4日に設立されるもより。参加したいけど、9月4日はすでに予定が埋まっているのでした。しくしくしく。