Open kenoss opened 9 years ago
提案内容には大賛成です。 カーソル色の変更が、うまくいってないことが度々発生するので、気になっていました。
「状態の変更を伝えたらよしなにカーソルを変更してくれるライブラリ」というのは、具体的にはどういったものをイメージしてますか?
ライブラリ自体は、hook等による状態の変更を検知する仕組みを持たない、ということでしょうか。
「状態の変更を伝えたらよしなにカーソルを変更してくれるライブラリ」というのは、具体的にはどういったものをイメージしてますか?
ライブラリ自体は、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 ステート決め打ちできるんで問題にはならないんですけど.
説明ありがとうございました。 従前の仕組みも残るわけですね。
修正の規模もかなり大きくなりそうなので、トピックブランチをきってから作業してもらった方が良いかもしれないですね。
楽しみにしてます!!
最近生活が変わってなかなか作業時間を確保できてないので, しばしお待ちを.
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 でどんなことができるか試してみます。進展があれば報告します。
(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 を使わなくて良くなるのは良いことかと思います。
Japanese is bellow.
I'm planning to separate common part related to cursor modification because:
I use Evil and advised as in http://d.hatena.ne.jp/tarao/20130304/evil_config . With this circumstance, I have
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
How do you feel?
以下の理由からカーソルライブラリの共通化をしようと考えています:
自分は Evil を使っていて, http://d.hatena.ne.jp/tarao/20130304/evil_config のアドバイスをしています. この状況で
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)なので
したいです. どうでしょうか.