thinca

環境教えてください。

DateTime 周りのバグをいくつか直したので、もう一度試してもらって良いですか?

関数の数が多すぎる気がします。 微妙に動作の違う関数がたくさんあると、ユーザはどれを使えばいいのかわからず混乱します。 似た機能の関数はまとめた方がわかりやすいのではないか、と言うのが私の意見です。

そもそも、1つの方法を推奨するつもりはないです。 好きなように使っていただければ。

help にするとして、`vital.txt` に書くか、独立したファイルに書くか、独立したファイルにするとしたらファイル名は何がいいか、などについて意見募集。もちろん根本の書く場所は help でいいのかについてももし意見があればください。

ちなみに私は独立したファイルの方がよさげな気がするけどファイル名が思いつかない派です。分ける根拠は、vital を使うだけの人は作る方法について興味がないだろうということと、それなりのボリュームになりそうだからです(独立したリポジトリで公開する方法なども含まれるため)。

example については完全に同意。

元々vital はバージョン(Git Hash)の名前のディレクトリにインストールされていたため、最新という意味で `__latest__` が使われていましたが、現在はプラグイン名のディレクトリにインストールされるように仕様が変わっていたため、現状に即していないということで変更しました。 ディレクトリ構成の変更については、基本的に互換性は重視しますが、絶対にないとは言い切れません。ただし現時点では特に予定はなく、可能性は低いです。

手順がまとまっていないのは完全にこちら側の落ち度です、すいません。(この Issue はそのためのものですね) 現状 `__latest__` を使っていても弊害はない想定です。vitalizer は runtimepath から外部モジュールを探す際に、 `autoload/vital/__*__/` のような感じでワイルドカードで探します。なので `__` で囲まれていれば実際はなんでも大丈夫です。 一方で、プラグインに外部モジュールを含める場合に、 `__pluginname__` のようにしておくと、vital のローダーは vitalize されたモジュール以外にここからもモジュールをロードします。なので可能な限りユニークな名前が好ましいです。 アナウンスについては、本件については今のところ特にしていません。外向けには互換性のある変更であると考えているためです。新しい機能は実験的な側面も大きいので、あえて周知せずに一部のコアユーザーが試用している状態です。 unite-vital-module のように vital の内部構造にガッツリ依存してしまうと問題は起きてしまいますが、内部構造は変わる可能性があるため、内部構造への依存によるリスクはユーザーの自己責任ということでお願いします。 アナウンスについてですが、正直なところ個人的には vital はそこまで使われていないだろうという思いもあったのですが、最近についてはそうでもなくなって来ているようで、もう少し気を配る必要があると考えさせられました。ありがとうございます。今後についてはアナウンス方法について検討したいと思います。重要な変更の場合には vim-jp の記事にするなどを考えたいです。

ありがとうございます。暇を見付けて順次取り込みたいと思います。 もちろん誰かやってくれても(ry