vital.vim
vital.vim copied to clipboard
vim-jp
A comprehensive Vim utility functions for Vim plugins
現状では help での example の記述方法が統一されていないので、仕様を決めてほしい。 今はこんな感じのがあります。 - 結果の表示方法 - echo で結果を書く - コメントで書く - == で書く - 関数の呼び出し方法 - 関数 - どこかで代入したと思われる変数.関数 - モジュール名.関数 ## 例 今は以下のような記述方法があります。 ### echo で実行結果を書く...
vital のモジュールは全てローダー経由で行われるので、ローダー側で save_cpo の処理を行えば、モジュール側の記述がちょっぴり簡潔になり、速度もちょっぴりだけ向上できそう。
good-bye `=`
~~Vimの仕様変更により、`=`が使い物にならなくなってしまったので~~、`=`はwildignoreを参照してしまうのでvital.vimから排除したいと思っています。 代用品としては fnameescape() くらいしかないですが、Vim 7.1.299 以上でしか使えない問題があります。 これについてはどうしましょうか。
#175 からの発展です。 > vital を利用したプラグイン制作者じゃなくて、vital を使用したプラグインの利用者が操作する仕組みだと理解して、E448 か E263 あたりがでたときに if_python 以外で動作するようにすれば解決するような気がしました。 で行けそう？
#189 から派生。 Vim のバージョンだけでなく、コンパイルオプション(`+clientserver` など)やプラットフォーム(Win/Mac/Linux)なども含めて、そのモジュールがサポートする Vim を規定できるようにする。 - [ ] ドキュメントの記法を決める - [ ] `_vital_xxx()` 的なやつでサポートする Vim をコードで指定できるようにする (詳細未決定) - [ ] サポートしていない Vim でテストを走らせた場合は該当モジュールのテストはスキップするように - [ ] サポートしていない Vim...
Lingrにて、「devブランチがある方がよいのではないか」「ホイホイpullreqマージしちゃって大丈夫なのか」という議論がありました。 僕の意見は「devブランチ不要。実験的新機能はExperimental. namespace以下に配置。実験的な既存モジュールの書き換えはそのたびにtopic branchをつくる」です。 一般に、devブランチがある方がよいのは、masterブランチが常に安定している必然性があるプロジェクトです。vitalの場合は比較的masterブランチの新規不安定moduleの追加に関しては緩やかでよい、というのが僕の意見です。新しいmoduleが入っても、vitalを利用してるプラギンがVitalizeで利用中moduleをアップデートしたところで、なにも壊れないからです。 masterブランチにある新しいmoduleを試してみようというとき、そのmoduleに高い安定性を期待するかしないか。vital開発者側の立場としては「どの程度期待するかは自己判断でお願いします」で良いと思います。というのも、安定度を高めるためには実際にプラギンから使った上でフィードバックをもらうのが不可欠だと考えるからです。vitalでプラギンに利用可能にすることが、安定度を高めるよりも重要だと思います。 TODO: 汎用目的のdevブランチを作るのと、特定module(複数の場合も)の実験的な大幅な改変のためにtopicブランチを作るのの違いについて、反論があれば僕の意見もここにまとめる
#76 に対応した際に、今まで UTF-8 に強制的にエンコードされていたのが、全くエンコードされなくなってしまいました。 元々の要望に対応しようとした結果ですが、これは意図した結果ではないため、引数でエンコーディングを指定できるようにし、何らかの値で無変換(バイナリ)、デフォルトは UTF-8 になるようにしようと思います。 `encodeURI({param} [, {encoding}])`
`Data.List` モジュールには、`{list}` と `{expr}` を受け取る関数がいくつかありますが、その順序が関数によってバラバラです。 - `({list}, {expr})` - sort() - sort_by() - max_by() - min_by() - `({expr}, {list})` - span() - break() - all() - any() - partition() わかりにくいので統一したいと思うのですが、どうでしょうか。...
> vital 本体の API のドキュメントを書こうと思ったけど、import() とか load() の仕様の議論がまだ収束してないことに気付くなど。 > えーと、load の as 機能について。現状の load(['Foo']) がわかりづらいとの話だった気がする。 > 個人的には短く書けて気に入っているのだけど。 > 仕様整理。 > 1. load するとモジュールが V に置かれてそこからアクセスできるようになる。 > > ``` > V.load('Foo.Bar.Buz')...