平衡点

2017/02/01

_ VimFx での IM の制御

前回(平衡点(2017-01-26))の続き．

基本，作業環境はターミナルなので普段は IM は OFF になっていて欲しいので，vimperator を使っていた時には...

Vimperatorのコマンドラインで自動的にIMEをオフにする - 貳佰伍拾陸夜日記

はい．お世話になっていました．

で，同様の事を VimFx でもできないかなぁ，とじたばた． VimFx/api.md at master · akhodakivskiy/VimFxあたりを眺めつつ，locationChange event あたりをひっかけたら良いかな，ということで.

const ibus_toggle = '/usr/local/bin/ibus-toggle'
const ibus_toggle_args = 'off'
// force ibus off when location changed
vimfx.on('locationChange', ({vim}) => {
    let file = Cc['@mozilla.org/file/local;1'].createInstance(Ci.nsIFile)
    file.initWithPath(ibus_toggle)
    let process = Cc['@mozilla.org/process/util;1'].createInstance(Ci.nsIProcess)
    process.init(file)
    args = ibus_toggle_args.split(' ')
    process.run(false, args, args.length)
})

と，こんな感じだろうか．とりあえず，日本語打つときは location bar での検索ぐらい(ページ内検索は XUL/Migemo)なので，ページ遷移があれば ibus を強制的に off にできるようになった．

あ，ibus-toggle の実態は

#!/bin/sh
[ -x /usr/bin/xdotool ] || exit 0
[ -x /usr/bin/ibus ] || exit 0
CURRENT_STATE=$(ibus engine)
case $@ in
    on|ON|enable|Enable)
        if [ ! ${CURRENT_STATE} = 'skk' ] ; then
            xdotool key "Super+space"
        fi
        ;;
    off|OFF|disable|Disable)
        if [ ! ${CURRENT_STATE} = 'xkb:us::eng' ] ; then
            xdotool key "Super+space"
        fi
        ;;
    *)
        # logger "ibus-toggle: toggle"
        xdotool key "Super+space"
        ;;
esac
exit 0

と，こんな感じ．本当はibus engineで指定したい所なのだが，コマンドラインから切り替えると GNOME shell との表示が乖離してしまうので，xdotool でキー入力している．

[ツッコミを入れる]

2017/02/02

_ GitIO を試してみる．

手元でデータを更新 ⇒ push で反映，とかできないかじたばたしている．既に tDiary2形式(テキスト)を Git で管理するプラグインを ClearCode さんが公開しているので，まずは日記データを GitIO 経由でコミットできるかテストしてみることに．

clear-code/tdiary: tDiary related software for http://www.clear-code.com/blog/.

はてさて，どうなるだろうか...

Emacs の tdiary-mode から tdiary-replace で更新してみると，HTTP fetch: connection timeout が返されたが，日記自体は更新されている様だ．外部リポジトリから更新する場合にはどうするかな? 試しにやってみると，データ自体は更新できるけれど，update.rb 叩いた訳じゃないので，RSS の生成とか cache の更新とかがうまくない(そりゃそうか)．こまんどラインから，データ本体ではなく付属するプラグインまわりだけ kick できれば良いんだけれど．

_ 続いて posttdiary-ex.rb を試してみる．

幸い(?)な事に postfix 動かしているので，procmail に仕込んでみる事に．

...ああ，https 対応してない? もしかして...?

_ というわけで tdiary-mode に戻る

やっぱりね．

http.el などの apel 依存とか，気になる所は多いので，こっち書き変えた方が良いんだろうな...．

[ツッコミを入れる]

2017/02/03

_ tmux 2.3 での East Asian Ambiguous Character

tmux が 2.3 に上がってから，emacs -nw で SKK 使って文字を入れていくとズレズレになって悲しくなっていた．状況としては，半角分ズレた所に確定した文字が入力されて，どんどんズレていく，といった所．ロケール弄ったし，wcwidth の値も Emacs 側での文字幅の設定もあっている筈なのに，ぐぬぬ．

...とかやっていた訳ですが．

ようやくすっりした，というか

tmux 2.2 からは wcwidth(1) を使うようになり、独自テーブルをやめてロケールの情報から文字幅を得るようになった https://github.com/tmux/tmux/commit/26945d7956bf1f160fba72677082e1a9c6968e0c 。が、このコミットをよく見ると setlocale(LC_CTYPE, "en_US.UTF-8") で固定されており、LC_ALL や LC_CTYPE に関係なく en_US.UTF-8 が使われる。 tmux は UTF-8 を前提としており、そこを固定したい気持ちは分からなくもないが……

[from:tmux 2.2 以降で East Asian Ambiguous Width Character を正しく表示させる方法]

というわけで，

曖昧文字幅を二文字幅にする．← wcwidth-cjk や locale の直接修正で
tmux.c での setlocale(LC_CTYPE, "en_US.UTF-8") を止め，setlocale(LC_CTYPE , "") とする

としたところ，状況が改善．あとは pane border．

aptitude なんかだと checker board なんかも使われるので，思いきって ACS エントリ全部 ASCII で書き変えてみたら，良い感じに．曖昧じゃない一文字幅の ACS entry に入れられる罫線文字種ってないかな...．

(追記) 単に ACS 全部使うだけなら，それはそれで良いんだけれど，最近の VTE ベースの端末は ACS を Unicode の Box Line Drawing char で表示するので問題が元に戻ります．rxvt-unicode なんかだと，幅は locale を見てくれるし，ACS はそのまま表示してくれるので，辻褄が合って大変良い状況なのですが...

[ツッコミを入れる]

2017/02/05

_ あい変わらず xmlrpc のテスト

metaWeblog.newPost を叩いての投稿テスト中.

行をあけないと，勝手にタイトルになるのかな?

カテゴリの付き方なんかが，記法に依存しているのかな?

ああ，違うのか．post した時点で，タイトル行中の「カテゴリ」がパースされてしまっているのか．そうすると，記事本体の投稿と「カテゴリ」の設定を別途行なえば良いのかな?

リンクは貼れるのかな? 単にテキスト流し込んでるだけなら，大丈夫そうではあるけれど．

前々回: 平衡点(2017-01-23)
前回: 平衡点(2017-01-25)

リンクは記法通りに貼れそう．そうすると日記の「カテゴリ」の扱いが鬼門かな?

とりあえず

mt.setPostCategories で [] を渡して，既存の日記のカテゴリをクリアする
metaWeblog.editPost でカテゴリ指定したタイトル付きで日記を投稿

で，良い様だ．

そういや，空のエントリに editPost で投げるとどうなるのかな?

だめそうだな．getPost に反応があったら editPost で，そうじゃなかったら new なんだろうか? うーん...．

_ emacs から tDiary を更新するために(1/n)

emacs-pe/http.el を導入してしまい，tdiary-mode が動かなくなってしまったので，そろそろ更新すべきだな，といわけで，じたばたし始めた．

いや，今のままでも tdiary-mode 自体はあって，Debianの場合には apel もちゃんと更新されているおかげで，Emacs25 での編集作業にも問題は無いのではあるが(単に tdiary-mode 同梱の http.el を rename すれば良いだけ)．

前エントリで xmlrpc を試していたのは，既に punchagan/metaweblog があるので「これ使ったら良いんじゃない?」的安易な発想であった訳なのだけれど，そもそもきちんと決まった API 一覧があるわけでも無さそうだし「カテゴリ」がついたりつかなかったりして，ちょっと気持が良くない(一応，emacs から metaweblog を叩くことで，buffer 内容を投稿したりすることはできたのだけれども)．

...続く.

_ Software Design 2017 2月号

購入

ソフトウェアデザイン 2017年 02 月号 [雑誌]
技術評論社, ￥36

そろそろ職場で定期購読したいなぁ(棒)

_ OCN モバイル ONE を契約

一年定額で利用していた SIM の契約期間が切れた．普段はともかく出張先なんかでいつも通りに使ってしまうと，あっというまに3日制限にひっかかるので，これまで1年間強を定額で購入していた SIM を更新するのは止めた．

ということで，「3日制限が無い SIM」ということで OCN モバイル ONE を契約．

OCN モバイル ONE エントリーパッケージ [音声対応SIM / SMS対応SIM / データ通信専用SIM] (ナノ / マイクロ / 標準サイズ対応)
NTTコミュニケーションズ, ￥300

そもそもメイン回線のドコモの契約でも 2GB/月を使い切れていないわけで．出張時にバーストモード(だっけ?)に切り替えることにしておいて普段は 110MB/日でも良いかもしれない，と最初は思ったり．とはいえ，考えてみれば翌月まで通信容量の繰越があるので，必要な時期にマルっと 6GB弱まで使えるという安心感のために，月に缶コーヒー2本分ぐらいの投資はしても良いか，ということで， 3 GB/月のプランで運用してみる．

使用感など，気がついた事があったら別途書く．

[ツッコミを入れる]

2017/02/08

_ (解決) tmux で EAW二文字幅としてこの先生きのこるには

前回(平衡点(2017-02-03))「ようやくすっきりした」とか書いておきながら, 結局どうしたら良いのか書いていなかったので.

結論

お使いのターミナル次第ですが

EAW 二文字幅派、一文字幅派どちらの場合においても、罫線描画に ACSC String を指定した際にこれをそのまま描くターミナル(rxvt, st, オプションで指定できる mlterm 等)の場合には、pane-border を弄る必要は無いと思われる。一方で、gnome-terminal 等の様に Unicode の BOX Drawing Char で描画するターミナルの場合にはpane-border に使われる文字を ASCII に置き換える必要がある。
ロケールを弄ることができる環境(個人の計算機、Mac OS の場合にはドコを弄るのか知らないけれど)であれば、en_US.UTF-8 と ja_JP.UTF-8 のロケールにおいて EAW のレンジにある文字の幅を明示しておけば良い。一方で、ロケールを弄る事ができない場合には、tmux.c 内の setlocale(LC_CTPYE, "en_US.UTF-8")の部分を修正した上で、fumiyas/wcwidth-cjk 等で、wcwidth を上書きして tmux を実行する。
フォントは適宜。二文字幅で生きる場合には、選択肢は多そう(日本語フォントの多くは EAW が二文字幅)。一文字幅で生活したいなら wacky612/ricty-custom とか Ufo by akahuku 等を使うのかな?

patch は二つ。

一つ目は pane-border 等、全て ASCII で描くパッチ。

二つ目は en_US.UTF-8 決め打ちを止めるパッチ。

一つ目のパッチは option として pane-border-ascii が追加される。初期値は 1 であり、オプションを指定しない場合には罫線描画に ACSC String が使われる。~/.tmux.conf 内で

set-option -g pane-border-ascii 0

と有効にすると、罫線描画に ASCII が使われる。

二つ目のパッチは、en_US.UTF-8 決め打ちを止めるパッチで、これを当てない場合には、カーソルの移動幅等の算出に en_US.UTF-8 が使われる。カーソル移動の際に、行中に文脈依存で幅の変わる EAW 文字種があろうが無かろうが、常に一文字幅でカーソルが移動するため、結果として悲惨な事になるだろう。

そもそも何が問題なのか

Wikipedia 先生に書いてありますが:

というわけで, Unicode の定義において *「文脈依存で幅が変わる文字」* があるわけで。(以下、EAW 文字と呼びます).

歴史的事情を汲んでくれた、と解釈すべきなのかな。とはいえ、ターミナルで生活している/していたい人(=私とか)にとっては、文字幅が時と場合によってヒョコヒョコ変わってしまって大変。

EAW 文字の取り扱い。

個々のアプリケーション毎に EAW 文字をどう扱うか対応している場合もあるけれども、その一方で、rxvt の様に「libc の wcwidth が返す値を使う」というアプリケーションもある:

[Bdebian-devel:16693] East Asian Width Problem at rxvt-unicode-ml

数式が描かれたテキストや、過去のしがらみが無い場合には「EAW など知らん。この範囲の文字は 1 文字幅だ!」として、とくに問題は無いだろう。

ただし、現状の日本語フォントの多くが EAW文字が二文字幅であることを想定して作成されているため、「半分だけ表示されるんですが...」という状況を許容するのであれば。
また、ロケールのデータ自体では EAW のままなので、表示と wcwidth の返す値を揃えるためには、ja_JP.UTF-8 が参照するロケールにおいて、EAW 文字の幅を "1" にしておくのが望ましいだろう。これが異なる場合にどんな祟りがあるのかは、試していないので良く知らない。

一文字幅派の利点は UTF-8-demo.txt が綺麗に表示される所かな。あと、割と少ないのだけれど、EAW 文字を 1 文字幅としているフォントを使うのが良いだろう。例えば、

とか?

一方で、過去の慣習から EAW 文字種が二文字幅であることを前提にして作成されたテキストも多々あって、これらをターミナル内できちんと表示させたい場合には、やはりEAW 文字は二文字幅の方が嬉しい。

gnome-terminal 等には EAW 文字を半角とするか、全角とするかというオプションがある。
rxvt 等、wcwidth の返す値を使うターミナルの場合には, ロケールデータを修正するか fumiyas/wcwidth-cjk 等で wcwidth を上書きすれば良い。

tmux ではどうするか。

tmux <= 2.1 までは、自前で文字幅に関する情報を持っていたのでここに wcwidth 相当の修正を加えることで幸せになれていた。

tmuxの文字幅がおかしい問題をクリアするpatchたち(一応charmapの続きなどの続き) - コンピュータ技術者になるための備忘録

一方、tmux 2.2 から wcwidth を参照するようになった。

tmux 2.2 からは wcwidth(1) を使うようになり、独自テーブルをやめてロケールの情報から文字幅を得るようになった https://github.com/tmux/tmux/commit/26945d7956bf1f160fba72677082e1a9c6968e0c 。が、このコミットをよく見ると setlocale(LC_CTYPE, "en_US.UTF-8") で固定されており、LC_ALL や LC_CTYPE に関係なく en_US.UTF-8 が使われる。 tmux は UTF-8 を前提としており、そこを固定したい気持ちは分からなくもないが……

[from:tmux 2.2 以降で East Asian Ambiguous Width Character を正しく表示させる方法]

でもって、何が問題かと言えば、上記にも書かれている通り、en_US.UTF-8 では EAW文字は一文字幅なので、二文字幅派にとってはカーソル移動/再描画の際に常に悲しみがつきまとう事になってしまう。

また、これは前からそうであった気もするが、pane の境界の描画に使われている罫線文字として Unicode の BOX DRAWING CHAR が使われている。これは EAW 文字であるため、tmux で上下分割すると、pane の境界線が二倍の長さで表示されてしまう(ため、ズレる)。

多くの人はこれに困りはてて、pane 境界の描画に ASCII を使い、wcwidth 相当の文字幅の算出関数を tmux 側で持つ、などといった修正を行なっている。

tmux 2.3 において East Asian Ambiguous Character を全角文字の幅で表示する

今回の記事は、結局のところ上記パッチでは私の欲求に答えられなかったのでじたばたした、というお話なのである(長いよ)。

で、結局どうしたのさ?

何が問題なのか、と言えば

幅の算出の際に en_US.UTF-8 決め打ちなので、EAW 文字があるとズレる
pane 境界の描画に使う文字種だけが ASCII になっているので、curses ベースの端末アプリケーションの多くがズレる。

ということであろうか? 特に aptitude や alsamixier がズレてしまって、悲惨な目にあった。

いろいろ書いたけれど、

手元の環境のロケールデータをEAW文字と絵文字(level1)を全て全角として扱う修正ロケールデータにおきかえる。ちなみに、作っていたのは以下:
- uwabami/locale-eaw-emoji: UAX#11 Ambiguous と UTR #51 Emoiji を全角とする修正 locale
微妙に間違っている気がしないでもないが、まあ良いか、的な。
- hamano/locale-eaw: East Asian Ambiguous Width問題と絵文字の横幅問題の修正ロケール
こっちの方が良いかもしれない。
最初に載せた二つのパッチを当てて、tmux 2.3 をビルド。
rxvt の場合には特にオプション等の指定は不要。 gnome-terminal 等、BOX DRAWING CHAR を使うターミナルを使う場合には tmux 内で pane-border-ascii 0 を指定する

ということをやって、今は幸せになれました、とさ。

ASCII 描画、ACSC 描画そして(元々の) Unicode BOX DRAWING CHAR は、オプションで選べると良いのではないだろうか、とか思いました。

en_US.UTF-8 決め打ちに関しては根が深そう、というか。なんでこんな安直に決め打ったんだろうか...。

[ツッコミを入れる]