Common cursor library カーソルライブラリの共通化

[kenoss]

Japanese is bellow.

I'm planning to separate common part related to cursor modification because:

• There will be confliction when some apps change cursor simultaneously;
• I doubt the code of SKK is good. (I don't read thoroughly related part of SKK yet.)

I use Evil and advised as in http://d.hatena.ne.jp/tarao/20130304/evil_config . With this circumstance, I have

• Cursor will be that of insert state after SKK mode on -> normal state with ESC key;
• Cursor will be that of normal state after SKK mode on -> SKK mode off.

Couple of months ago, Evil had used post-command-hook. So I didn't have impairment.

https://bitbucket.org/lyro/evil/issue/441/not-good-use-of-post-command-hook-for-evil

I don't think it is good idea to use hooks for such problems. Besides integration is not enough. From this viewpoint, ccc is too thin. (#3) There will be confliction.

So I wanna

• separate and use a library that treat well stateful cursor
• modify related part of SKK (and Evil)

How do you feel?

以下の理由からカーソルライブラリの共通化をしようと考えています:

• 複数のコードからカーソルの変更をすると競合する
• SKK のコードに疑問符が浮かぶ部分がある

自分は Evil を使っていて, http://d.hatena.ne.jp/tarao/20130304/evil_config のアドバイスをしています.
この状況で

• SKK モードから ESC でノーマルステートに抜けようとすると一度カーソルがノーマルステートのものになった後, インサートステートのものになる
• SKK モードから skk-mode でインサートステートに抜けようとするとカーソルがノーマルステートのものになる

という現象が確認されています. 以前は Evil はカーソルの変更に post-command-hook を使っていたので気付きませんでした.

https://bitbucket.org/lyro/evil/issue/441/not-good-use-of-post-command-hook-for-evil

自分はこういった問題に対して hook の順番で対処するのは泥沼になるだけだと感じます. (integration を全部個人に任せるというスタンスなら残念ですが.)
その観点からは ccc は共通ライブラリにするには薄すぎると思います. (#3)

なので

• 状態の変更を伝えたらよしなにカーソルを変更してくれるライブラリを分離
• その他にカーソルに関わる SKK のコードを整理

したいです. どうでしょうか.

[myuhe]

提案内容には大賛成です。
カーソル色の変更が、うまくいってないことが度々発生するので、気になっていました。

「状態の変更を伝えたらよしなにカーソルを変更してくれるライブラリ」というのは、具体的にはどういったものをイメージしてますか？

ライブラリ自体は、hook等による状態の変更を検知する仕組みを持たない、ということでしょうか。

[kenoss]

「状態の変更を伝えたらよしなにカーソルを変更してくれるライブラリ」というのは、具体的にはどういったものをイメージしてますか？

ライブラリ自体は、hook等による状態の変更を検知する仕組みを持たない、ということでしょうか。

• hook などは使わず, (ライブラリユーザが)アプリケーション毎に事前に状態を登録しておき, 状態の変化が通知されたらその登録された情報からカーソルを変化させる. アプリケーションの優先度も管理する.
• よくある hooks and advices の組み合わせを提供する.

の二段階で考えています. 例えば,

(xxx-register-states '(evil (normal insert visual emacs)))
(xxx-register-states '(skk (neutral japanese latin)))
(xxx-set-link '(evil insert) '(skk))
(xxx-set-link '(evil emacs) '(skk))

(xxx-register-state-detail '(evil)        :cursor 'hbar)
(xxx-register-state-cursor '(evil normal) :cursor '("darkolivegreen"))
(xxx-register-state-cursor '(evil insert) :cursor '("#800000" (bar . 2)))
(xxx-register-state-cursor '(evil emacs)  :cursor '("#999999" (bar . 2))
                                          :theme 'hogehoge)

(xxx-register-state-cursor '(skk)          :cursor nil)
(xxx-register-state-cursor '(skk japanese) :cursor '("#eb6101"))

(xxx-localize-state '(evil) 'buffer) ; add hooks and advise

としておいて,

(defun skk-j-mode-on (&optional katakana)
  (setq skk-mode t
    skk-abbrev-mode nil
    skk-latin-mode nil
    skk-j-mode t
    skk-jisx0208-latin-mode nil
    skk-jisx0201-mode nil
    ;; sub mode of skk-j-mode.
    skk-katakana katakana)
  (skk-setup-keymap)
  (skk-update-modeline (if skk-katakana
               'katakana
             'hiragana))
  (xxx-inform-state-change '(skk japanese)))

みたいな感じですね. ただ欠点として, evil-insert-state-modes などの関係で Evil 側の変更が大きくなりそうなんですよね.
SKK だけだと insert か emacs ステート決め打ちできるんで問題にはならないんですけど.

[myuhe]

説明ありがとうございました。
従前の仕組みも残るわけですね。

修正の規模もかなり大きくなりそうなので、トピックブランチをきってから作業してもらった方が良いかもしれないですね。

楽しみにしてます！！

[kenoss]

最近生活が変わってなかなか作業時間を確保できてないので, しばしお待ちを.

[masatake]

ddskkやevilが様々なバージョンのEmacsで動いていることを考えると根源的な解決にはならないのですが、Emacs側がインターフェイスを提供して欲しいですね。

プリミティブとしてselect-windowのタイミングでemacsからコールバックしてくれれば9割方解決したように記憶しています。残り1割それでは不十分なケースがあったような気がするのですが...
select-windowにフックが無いのは、select-windowの処理がemacsの中枢にありすぎて、そこでフック関数が余計なことをするとさっぱり動かなくなるからでは、とどこかで読んだか、勝手に想像していました。(set-bufferの間違いか？) もしこのことが正しとしても select-windowの中枢の処理が終っただいぶ後にhookがあれば良いように思います。別のissueに書きましたが、buffer-list-update-hookが使えるかもしれません。

@kenoss さんの考察によれば、プリミティブだけではだめで、カーソルの使い方を複数のライブラリで奪い合うことがあるので調停する仕掛けが必要なようですね。その仕掛け、cursor arbitratorは、プリミティブの上にのせると。最後にskkやevilなどがcursor arbitratorを利用する。位置付け上cursor arbitratorまでEmacs側に欲しいように思います。

buffer-list-update-hook でどんなことができるか試してみます。進展があれば報告します。

[masatake]

(defvar my-counter 0)
(add-hook 'buffer-list-update-hook
	  (lambda () (message "%d hello" my-counter)
	    (setq my-counter (1+ my-counter)))))

これを評価して C-x oとかC-x 5 2とかしてみたのですが、エコーエリアの表示を見る限り良い感じです。
cursorの色を切り替えて欲しくなるようなタイミングでカウンターが増えています。みなさまどうでしょうか？

emacsの改変履歴を少し調べていると2011年に導入されたようです。

commit 9397e56f7424b87f0b52be1235b25a56002661f1
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Sat Jun 11 11:50:37 2011 +0200

    Move/add window-buffer-related functions to window.el.
    
    * buffer.c: New Lisp objects Qbuffer_list_update_hook and
    Qclone_number.  Remove external declaration of Qdelete_window.
    (Fbuffer_list): Rewrite doc-string.  Minor restructuring of
    code.

buffer-list-update-hookを使うと、ccc.el中の

  (add-hook 'post-command-hook 'ccc-update-buffer-local-frame-params)
  (add-hook 'after-make-frame-functions 'ccc-setup-new-frame)

を消せそうです。issueの元の問題提起からは少しずれますが、post-command-hook を使わなくて良くなるのは良いことかと思います。