物置き

JACET8000

Smart.fmでのマスター単語数が5500を超えてきたので
こちらの語彙レベル測定CGIで「語彙レベル5000」で測定をしてみるも、
「5000語彙ありません」という結果になった。(4000語彙はあった)
この測定CGIではJACET8000という単語リストを基にしているとのこと。


ここで、このまま現在のリストを進めていって果たして大丈夫なんだろうかと不安になった。
今はAGOSのTOEFLシリーズを進めているのだけど、これを進めていってJACET8000の単語を埋めることはできるのだろうか。
(まあ、JACET8000をコンプリートするために勉強しているわけではないのだけど)


ということで、APIを使って現時点でのマスター単語一覧とTOEFLシリーズのリストに含まれる単語一覧を取得し、
それらをあわせたものと、JACET8000の単語リストとを比較してみることで、
TOEFLシリーズを終えた時点でどれくらいJACET8000をカバーできるようになるのか調べてみようと思った。


とはいえ、JACET8000の単語リストはオープンにはなっていなくて、有償で入手する必要がある。
これだけのためにお金払ってまで調べる気にはなれないので、
代替として北海道大学英語語彙表というのを使ってみることにした。
(こちらの語彙表の単語数は7454でJACET8000と比べるとちょっと少ないけど、
目的柄きっとJACET8000と似通ってたもんだろうと予想)

任意のユーザのマスター単語一覧を取得(現在のバッファに出力)

function! GetSmartfmMasteredItems(user_name)
  let smf = smartfm#initialize("")
  
  let offset=0
  while 1
    let offset = offset + 1
    let res = smartfm#get_studied_items(smf,a:user_name,100, offset, "studied",1,0,0,100,100)
    if len(res) == 0
      return
    endif
    for _ in res
      let line = '"'._['cue']['text'].'","'._['responses'][0]['text'].'"'
      exe "normal! Go".line
    endfor
  endwhile
endfunction

任意のリスト内アイテムの一覧

function! GetSmartfmListItems(list_id)
  let smf = smartfm#initialize("")
  
  let offset=0
  while 1
    let offset = offset + 1
    let res = smartfm#get_items_in_list(smf, a:listid, 100, offset, 0)
    if len(res) == 0
      return
    endif
    for _ in res
      let line = '"'._['cue']['text'].'","'._['responses'][0]['text'].'"'
      exe "normal! Go".line
    endfor
  endwhile
endfunction
      • -

わざわざVimScriptでやるのが意味不明な感じだけど、
自前のAPIラッパーを流用できて一番楽ちんだから。(APIラッパーはsmartfm_frontend.vimに含まれている)


上記のスクリプトを使って単語済み一覧を取得し、北海道大学英語語彙表と比較してみたところ、
現時点での語彙表上のマスター単語数は3577だった。
3577 / 7454ということで分母を8000に通分してみると、約3839
まあ、ぎりぎり4000語彙あるかというくらいで、測定CGIのお告げの通りになった。

      • -

あと、この先自分がやろうと思っている(Smart.fm上の)リスト群をコンプリートしても、
自分が期待するほどJACET8000の単語を埋めることはできないということもわかった。まあ仕方ないか。

カーソル移動にあわせてCSVの列をハイライトする

Vim Hacks - Hack #78: CSVの特定のカラムをハイライトする


上の記事を見て、ハイライトがカーソル移動に追従したら面白そうだと思ったので試しに実装してみました。

ついでに、二重引用符で囲ったcommaを考慮するような変更もしたけど、
RFC4180の仕様に乗っ取ったりなどしているわけでは全然なく、そのへんはちょう適当です。


カーソルが移動する度に、現在の位置が何列目にあるかを調べているので、
データの規模・書式、あるいは実行環境によって重くなることがあるかもしれません。
ただ、手元にあるいくつかの.csvファイルで試した限りでは特に気になりませんでした。

使い方

拡張子.csvのファイルを開いた時は自動的にハイライト機能が有効になります。

それ以外のファイルをハイライトしたい場合は、このスクリプト内で定義しているコマンド:CsvColHighlightを実行してください。
ハイライトを止めたい場合は、:CsvColNohilightでできます。

ダウンロード

csv_auto_highlight.vim

Windows,Vim7.2でしか動作確認してません。

マルチバイトを含まない大きめのファイルを開くと時間がかかる

自分のPCで、大きめのファイル(20MByteくらい)をVimで開いた時に、
同じファイルを他のテキストエディタと開いた時と比べて
妙に時間がかかることがあって、いったい何だろうなあと思いつつもそのまま放置していたのだけど、
ふと思い立ち、調べたので以下にメモ。

環境はWindows版のVim7.2(Kaoriya版)。

原因

Kaoriya版に標準添付されている、verifyenc.vimが原因だった。

このプラグインはファイルを開いた時(BufReadPostイベント発生時)に
VerifyEncodingという関数を呼ぶ。
この関数では、開いたファイルの&fencが正しいかを調べているらしいのだけど、
処理のはじめの方で、ファイル内にマルチバイト文字が含まれるかどうかをsearch()関数でチェックしている。
マルチバイトを含まないファイルで、「マルチバイトがあるかどうか」という検索をすると、結果的にファイルを丸ごと検索してしまうことになる。
マルチバイトかどうかを判断するパターン('[^\t -~]')も相まって、時間がかかってしまうみたい。よくわからないけど。


そんなわけなので、非Kaoriya版だとこの現象にでくわすことはなさそう。

対応

g:verifyenc_enableという変数に0を設定しておくと、
このプラグインの機能が無効になる。これで特に時間がかかることはなくなった。

とりあえずこれでしばらく様子を見て、
問題なさそうであれば削除するとかでよさげ。
(せっかく添付してくださってるものを削除するのもなんだけど)

textobj-parameter 0.1.0

変更点

「a,」での選択時の挙動を変更

以前のバージョンの「a,」は一階層上の関数呼び出しの引数を選択するというものでした。




が,実際使ってみると、この機能は個人的に全く使わないことが判明したので、
区切り文字(,)を含めた範囲を選択という挙動に変更しました。


ということで、
「i,」は区切り文字を含めない形での引数選択
「a,」は区切り文字を含めた形での引数選択
という形に変更しました。

i,での選択



a,での選択



ダウンロード

textobj-parameter 0.1.0

--remote-waitオプション

自分の環境では、.vimperatorrc

set editor='C:/Path/To/vim72-kaoriya-w32j/gvim.exe --remote-wait'

などと設定した状態で外部エディタとしてVimを起動すると、
たまにVimでの編集を終了してもVimperator側が復帰しない(Vimの終了を待ち続ける)ことがあって、なんだろうなあとは思いつつも、特に原因について調べるようなことはしていなかった。


で先日、2009-11-12 rrhelper.vim - KBDAHOLIC - やぬすさんとこを見て、remote-wait周りの処理がrrhelper.vimで行われていることを知り、この周りを調べれば問題の原因がなんかわかるかもと思って調べたところ、なんとなく原因がわかったので以下にメモ。


どうもこの現象は、Vimでファイルを開いた後でバッファのカレントディレクトリを変更すると起こるみたい。
(BufEnterイベントで自動的にディレクトリを変更するような設定をしていると遭遇しやすいかも)


vimで開く

別のバッファに移動

元のバッファに戻る(BufEnter) <- ここでディレクトリ変更が発生

バルス


こんな感じで、カレントディレクトリを変更した際にファイル(バッファ)名が変わってしまって(C:/Path/To/filename -> filename)
そのせいで、rrhelper.vim内でautocmdに追加されたパターンと一致しなくなってしまっている模様。

rrhelper.vim内での処理

サーバ側でファイルを開く際、 そのファイルのバッファがアンロードされる時にクライアント側に何か応答を返すための処理がautocmd BufUnloadイベントとして追加される。
(rrhelper.vimのSetupRemoteReplies関数)

その際、autocmdに加える時のパターンがファイルのフルパスで登録される。
ところが、:lcdでカレントディレクトリをバッファのファイルと同じディレクトリに変更すると、
ファイル名が、途中のディレクトリが省略されたものになってしまう(例:/path/to/filename -> filename)

すると、BufUnloadイベントが発生した時のファイル名とパターンとの比較で合致しなくなる

クライアントへの応答処理が呼ばれないまま

Vimを終了するまでクライアント(Vimperator)側は待機したままになる。

ということで

この現象を回避するようrrhelper.vimを修正したのでここに晒しておきます。
(「vimperator」,「remote-wait」でぐぐってもほとんどヒットしないので、こんな現象に嵌っている人は他にはいなそうですが..)


rrhelper.vim 修正版

Vim7以降でしか動作しません。Windows上でしか動作確認してません。

smartfm_frontend.vim 0.0.2

goals studied APIコールの出力形式の変更に伴う修正

  • 動かなくなってしまったのを修正
  • 変更により、urgentの項目がとれなくなったので廃止

smartfm_frontend 0.0.2

2010-04-05 追記

2010-04-05現在、上記スクリプトではログインできなくなっています。

修正版(0.0.3)