Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unite-outlineの引数に、任意のファイル名を取れるようにする #26

Open
Shougo opened this issue Dec 29, 2011 · 5 comments
Open

Comments

@Shougo
Copy link

@Shougo Shougo commented Dec 29, 2011

http://twitter.com/hrsh7th さんが、unite-outilneを使って補完を実現しようとしているみたいで、
それは面白いと思ったので要望。
現在の仕様だと、(おそらく)カレントバッファしかキャッシュ・アウトライン表示できない仕様だと思うのですが、
これを引数で可変にできるようしてほしいです。
引数に与えられたファイルをキャッシュして表示します。与えられなければ、これまでどおりの挙動。
実装は簡単でないかもしれません。

@h1mesuke

This comment has been minimized.

Copy link
Owner

@h1mesuke h1mesuke commented Dec 30, 2011

現在の仕様だと、(おそらく)カレントバッファしかキャッシュ・アウトライン表示できない

ご指摘の通り、unite-outline では見出し抽出の対象が「現在のバッファ」であり、ファイルではありません。見出し抽出のロジックに「現在のバッファ」に対して作用する組み込み関数(searchpos() など)が使われているほか、

  • 未保存の新規ファイルや nofile なバッファなど、ファイルと結び付いていないバッファでも見出しが抽出できなけれならない
  • CursorHold で見出しを更新する場合、ファイルから見出しを抽出するわけにはいかない(変更部分が未保存の場合、最新の見出しを得るには現在のバッファから抽出する必要がある)

といったこともあって、unite-outline の見出し抽出は「現在のバッファ」と密に結合しています。

で、結論から言うと、「現在のバッファからしか見出しを抽出できない」という制約については、私自身も問題だと考えていて、これは解決したい課題のひとつです。

というのも、現在表示中ではないバッファ(ファイル)の見出し一覧を別窓に出しておきたい、といった要望が既に何度かありましたし、

見出しの抽出と「現在のバッファ」との結合をなくせば、入力として任意のファイル名を受け取る関数として unite-outline を使えるようになり、応用範囲が広がると思うからです。

ですが、ご想像の通り、これはすぐにはできません。やるとしたら、ファイルはファイル、バッファは擬似的なファイル、として統一的に扱うような仕組みを考えなければなりませんし、「現在のバッファ」と密に結合している部分を置き換えなければなりません。

私自身がまだまだ勉強しなければならないということも含めて、来年いっぱいの研究課題、ぐらいのスパンでしょうか。

unite-outline の開発ロードマップ上にある課題だとは思いますので、長い目で見てもらえればと思います。

@Shougo

This comment has been minimized.

Copy link
Author

@Shougo Shougo commented Dec 30, 2011

了解しました。

未保存の新規ファイルや nofile なバッファなど、ファイルと結び付いていないバッファでも見出しが抽出できなけれならない
CursorHold で見出しを更新する場合、ファイルから見出しを抽出するわけにはいかない(変更部分が未保存の場合、最新の見出しを>得るには現在のバッファから抽出する必要がある)
といったこともあって、unite-outline の見出し抽出は「現在のバッファ」と密に結合しています。

これ自体は問題にならないでしょう。なぜなら、実装にgetbufline()を使えば済むからです。
searchpos()は使えなくなりますが……。

ですが、ご想像の通り、これはすぐにはできません。やるとしたら、ファイルはファイル、バッファは擬似的なファイル、として統一的に扱うような仕組みを考えなければなりませんし、「現在のバッファ」と密に結合している部分を置き換えなければなりません。

ふむ。ファイル前提なら、ctagsを使うとかして最適化できそうですからね。
ファイルが存在するかどうかで分岐する手もありそうです。

@h1mesuke

This comment has been minimized.

Copy link
Owner

@h1mesuke h1mesuke commented Dec 30, 2011

searchpos()は使えなくなりますが……。

これが結構痛いんですよね。
unite-outline が ctags などの外部プログラムを使うのは C/C++/Java のみで、それ以外のファイルタイプでは Vim script で見出しを抽出しているんですが、速度性能の肝がまさに searchpos() なので。

同等の機能をリストに対して行える方法(組み込み関数による)が見つかればなんとかなると思います。(match() にリスト渡せばいけるような気がする)

@Shougo

This comment has been minimized.

Copy link
Author

@Shougo Shougo commented Dec 31, 2011

ふむ。neocomplcacheのようにvimprocを使う手もありますが、あれはあれで大変なんですよね。

Emacsのanything.elでも、高速化するために裏バッファでsearchpos()みたいなことをしているらしいです。

(match() にリスト渡せばいけるような気がする)

確かに、それを使えばできそうですね。あとは速度がどうなのかですが……。

@h1mesuke

This comment has been minimized.

Copy link
Owner

@h1mesuke h1mesuke commented Dec 31, 2011

neocomplcacheのようにvimprocを使う手もあります

おお。そっちも検討してみます。

todesking pushed a commit to todesking/unite-outline that referenced this issue May 27, 2014
Fix ctags check for different global vars.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.