Results 14 issues of h1mesuke

見出し一覧を表示した時、カーソル位置に最も近い見出しを自動的にカーソル行にする機能 -no-quit で使った場合はリアルタイムにカーソル行が同期されるようにしたい。 が、場合によっては前回の位置にカーソル行が残っていて欲しい場合もあるだろうから、 オプション変数で ON/OFF するようにするか。 ちなみに、Tagbar はこれができる。

core

### 現在のやり方 Vim script でファイルを順番に開いていって :Unite outline を実行させ、結果を目視で確認、 OK かどうかをプロンプトにて答えていくというもの。 ### 問題点 ユニットテストに相当するレイヤーのテストがない。 内部のモジュール関数やスクリプトローカル関数が意図した通りに動いているか、きちんと検証できていない。 目視による確認が前提のテストなので自動化し辛い。 ファイルタイプの数も増えてきてそろそろ限界。テストするのも億劫になって悪循環。 ### 対応 ユニットテストに相当するレイヤーのテストを増やす。 unittest.vim を使う。必要な機能がいろいろ足りてないので追加して対応する。 目視による確認事項を最小限におさえ、大半を自動化、テストの負担を下げる。

現在、unite-outline の見出し抽出は非同期ではないため、見出しの抽出中はユーザーは他の操作が行えない。 大抵の場合、見出しの抽出は瞬時に終わるため、これが問題となる局面は少ないが、 以下の場合に、抽出時の待ち時間が大きくなり、無視できなくなることがある。 - 見出し抽出に外部プログラムを使う場合 - C/C++/Java における ctags の使用がこれにあたる - Windows では特にプロセスの起動が遅く、200行程度のバッファからの見出し抽出に1秒以上を要するとの報告があった - ファイルが大きい場合 - 数万行とかいう規模になってくるとさすがに厳しいか - マシンが貧弱な場合 このような場合でも、ユーザーをブロックすることなく見出しの抽出を行えるよう、 見出しの抽出を非同期に行えるようにすべきである。 ## 案1: vimproc を使う 一番有力な案。というか、これ以外にどういうやり方があるものかまったく思いつかないw もし、ユーザーが vimproc をインストールしており、かつ、オプションで非同期な抽出を許可する設定をしていれば、vimproc...

core

statusline にカーソル行が所属する見出しの word を表示したりといったことに使える。 見出しのリストはバッファローカル変数に入っており、個々の見出しは対応する行番号を持っているので、for でまわしてカーソル行の行番号と比較していけば、カーソル位置に一番近い見出しが見つかる。

core

絞り込み時に仮引数名などにマッチしないように word から仮引数名などは除外されているが、 たまに表示されている見出しそのものに対してマッチさせたくなる時がある。 パターンの前に ! を付けることでマッチングの意味を逆転させられるのと同じような仕組みで マッチ対象として abbr の方を選択できるようにできないか。ある記号をパターンに前置することでそうなるとか。

matcher

現在、JavaScript の見出し抽出は正規表現マッチ+create_heading() でやっているが、限界 実行時にならないとわからない情報が多いため、見出し間の親子関係が把握しづらく、ツリーが作りにくい。 また、OOP の流儀(書き方)もいろいろあるので、オブジェクトの役割(見出しの type)も判別しにくく、 適切なハイライトを設定することも難しい。 ## 案1: jsctags を呼び出す C/C++/Java で ctags を使うのと同様の発想。以下のエントリに触発されてのもの↓ Awesome vim support for javascript with jsctags and taglist-plus | discontinuously.com http://discontinuously.com/2011/03/vim-support-javascript-taglist-plus/ Miscellany: Introducing...

parser

この関数はインターフェースもひどい上に、heading でなく unite の candidate(outline info から見えるべきでない)が渡されてくるなど、どう考えても本体内部に隠蔽されているべき部分。これが outline info の仕様として露出しているのはよくないのでなくす。 で、このような関数を定義することなく formatter の振る舞い(空行をどこに入れるか)を制御できる仕組み、仕様を考えるべき。 outline info に formatting_rules のような属性を設定できるようにし、その値によって foramtter の振る舞いを制御するような方法が考えられる。

parser

ファイルタイプによっては連続する空白の圧縮が不都合な場合がある。 outline info の属性によって、この機能の ON/OFF を制御できるといいかも知れない。 省略時は ON で、既存の outline info は変更の必要なしとすべき。 問題は属性の名前 normalize_heading_word: 0 squeeze_whitespaces: 0 あたり?

parser
request
core

write と hold 以外の auto_update_event の選択肢として、見出しの更新を実際に表字する時まで遅延する show も欲しい。 write もどちらかというと、-no-quit で見出し一覧が常時表示されている状態を見越している。 この場合、:w のタイミングで見出し一覧が更新されのはそんなにおかしくない。 一方、見出し一覧が常時表示されているのでないなら、見出しの更新タイミングは実際にそれを表示するときまで遅延できる。 その場合、見出しを表示する時に待ち時間が生じるが、外部プロセスを呼び出すなどの理由で見出しの抽出にそれなりの時間がかかってしまうファイルタイプでは、見出しの更新を最低限に抑えられるし :w で毎回待たされることはなくなるので、全体として使用時のストレスは軽減できるのでは。

core

たまに絞り込み結果に小見出しも残って欲しい時がある。 絞り込み文字列(input) の末尾になんらかの記号をおくことでそれを指示する、とかはどうだろうか。

matcher