&enc==utf-8時、文字列に添え字でアクセスすると
文字単位でのアクセスになるという自分の認識 -> 誤り。正しくはバイト単位。(wchar_tのような感覚でいた)
utf-8の日本語文字、1バイト目は0xE0〜0xEF、2,3バイト目は0x80〜0xBFの値をとる。(<-要確認)
そのため&enc==utf-8環境では、テキスト文字列をバイト毎に評価しても、
2,3バイト目が誤ってASCII文字列と解釈され、
正規表現'\k'でのマッチングにヒットするという現象は(&iskeywordを変更しない限り)発生しない。
Windows環境下での&iskeywordの既定値は、A-Z,a-z,'0'-'9',_, 0x80-0xA7,0xE0-0xEB。
(0x80-0xA7,0xE0-0xEBという値は何を意味しているのだろう?)
これだと、cp932のテキストをバイト単位で評価した場合に全角文字を構成するバイトの一部が
&iskeywordとして判定され、その結果としてhtmlcomplete#CompleteTagsの戻り値で
不正な値を返すことがおこりうる。
だいたい、HTMLタグを区切るための判定に\kを使うことが間違っているような気がする。
ユーザの設定によっては挙動が変わってしまうし。
おそらく、htmlcomplete#CompleteTagsは全角文字を対象とはしていない。
(CompleteTagsなんて名前なくらいだから、基本的にはHTMLで使われるタグ名のみを対象としているはず..!)
現状の自作修正版は、バイト単位で評価していたものを文字単位で評価するようにしただけ。
根本的な解決策ではない。現状のおかしなコードにあわせた場当たり的な修正にすぎないという感じがする。
とりあえず目の前にある問題はこれで解決した(?)とはいえ、なんかすっきりしないなあ。
