Λlisue
Yes but not yet because vital.vim does not run tests on Neovim yet.
この問題に関しては二種類あると思います。 1. バージョンの違いによりモジュール全体が使えなくなる場合 2. バージョンの違いによりモジュールの一部の機能が使えなくなる場合 今回は話をシンプルにするために 1. だけ考えます（ 2. に関しても考えたほうが良さそうですが、たぶん別 issue ） 全体的に使えなくなる場合、インポートの意味すら無いため `import()` 時に例外を投げてくれたほうが使いやすいです。 ただ、後方互換にならないため ``` let s:Job = vital#vital#import("System.Job") " 例外を投げる let s:Job = vital#vital#import("System.Job", {'fail_silently': 1}) "...
想定ケースの違いですかね。僕は 1. インポートする意味がない場合 2. 一部の機能が使えない場合 の二種があると思って居ます。はやぶささんが仰る通り、例外に関しては 1. の対応しか出来ない上に 2. に対して別解を用意する必要があり一貫性がありません。 ただ、僕が想定しているケースとして「とりあえずそれっぽい名前があるからインポートして使っている」程度の認識を想定して居ます。この場合、インポート時に例外が発生すれば比較的早い段階で使えないことが分かるので、なんだかわからないけどエラーが出てプラグインが動かない」って状況を避けれるかなと思っています。 あと try-catch に関しては懐疑的です。引数や関数名であれば機械的に変換出来ますが try-catch だと厳しいです（そもそも後方互換はあくまでも利便性の為であり、推奨はエラーを出す方なので）
昨日の話し合いとして、頑なに例外を推していたのは自分だけだったのですが 1. 例外を採用すると必ず try が必要になってしまう 2. 逆に例外ではなくチェックであれば、例外を投げる選択肢を自分の裁量で採用できる 3. 例外もチェックもそれぞれ利点があって比較は難しい の三点から余力を残すために例外を採用しないでチェックで対応するという形で同意しました。 また、ここで言われている is_availabe() による真偽のテストではなく vital#plugin_name#health_check('module name') にて最低でも以下の情報を含む辞書を返す形で同意が取れています（たぶん * status : boolean, 使用可能か否か。一部使用可能な場合に true を返すかはモジュール作者の思惑依存 * reason : str, 使えない場合は理由。そのままエンドユーザーに表示する想定 上記に加え、一部利用できない関数などがあれば追加フィールドとしてモジュール作者に依存する また...
gina.vim で対応したので知見として該当PR貼っておきます https://github.com/lambdalisue/gina.vim/pull/25
各 Python に対応する場合は https://github.com/lambdalisue/gina.vim/pull/25/commits/67906f18206d93972ef2cbc4775080086d19f749 みたいな感じが必要だと思います（実験途中のコードなので、そのままだと動かない気がするけど） https://github.com/vim-jp/vital.vim/issues/430 https://github.com/vim-jp/vital.vim/issues/417
できれば HTTP だけじゃなくていろいろなの扱いたいですね。Websocket とか
> (concprocを使って実現できそうな予感力) curl, wget のあたりはそれがベストっぽいですよね。Pythonは内部でループ・スレッド化など全部やっちゃったほうが良さそう。Async にするところだけ concproc かなぁ
困ってるのが既存との関係性をどうするか？って部分です。僕の構想だと使い方変わり過ぎなので良いアイディア募集。