プラグイン作者向けドキュメント

gopls をエディタープラグインとしてエディターに統合する場合、エディターと gopls 間の通信には、LSP 仕様で指定されていないセマンティクスがかなり多く存在します。

ここでは、他のプラグイン作者に役立ったであろう詳細情報やその他の情報を記録するよう努めています。

ご自身でプラグインを実装していて、このページで回答されていない質問がある場合は、私たちにご連絡ください。そして、その発見をこのページに貢献してください。

サポートされる機能

gopls が機能をサポートしているかどうかを知るには、ほとんどの場合、機能のインデックスを参照する必要があります。

真に信頼できる回答を得るには、initialize リクエストの結果を確認する必要があります。ここで、gopls は ServerCapabilities でサポートを列挙しています。

位置と範囲

多くの LSP リクエストは、位置または範囲の情報を渡します。これは、LSP 仕様に記載されています。

ドキュメント内の位置（以下の Position 定義を参照）は、ゼロベースの行および文字オフセットとして表現されます。オフセットは UTF-16 文字列表現に基づいています。したがって、a𐐀b の形式の文字列の場合、文字 a の文字オフセットは 0、文字 𐐀 の文字オフセットは 1、文字 b の文字オフセットは 3 となります。これは、𐐀 が UTF-16 で2つのコードユニットを使用して表現されるためです。

これは、統合者は UTF-16 ベースの列オフセットを計算する必要があることを意味します。すべての変換には protocol.Mapper を使用してください。

編集

gopls からエディターに変更を配信するために、LSP は応答で TextEdit の配列をサポートしています。仕様には、これらがどのように適用されるべきかが正確に記載されています。

すべてのテキスト編集範囲は、元のドキュメント内の位置を参照します。テキスト編集範囲は決して重複してはならず、元のドキュメントの一部が複数の編集によって操作されてはなりません。ただし、複数の編集が同じ開始位置を持つことは可能です。複数の挿入、または任意の数の挿入の後に単一の削除または置換編集が続く場合です。複数の挿入が同じ位置を持つ場合、配列内の順序が、結果のテキストに挿入される文字列の順序を定義します。

すべての []TextEdit は、受け取ったデルタの配列を逆順に適用すると、仕様に準拠した目的の結果が得られるようにソートされています。

エラー

LSP 仕様には、さまざまなエラーコードが記載されています。メソッドがエラーを返すことの意味についてはまだ検討中です。エラーは低レベルの LSP/トランスポートの問題のみを対象とするのか、それとも他の条件がエラーを返す原因となるのか。この議論の一部については、#31526 を参照してください。

現在選択されている方法は、現在人気のあるエディター統合における正確な処理に影響を受けています。これは変更される可能性があり、理想的にはリクエスト全体でより一貫性を持つようになるでしょう。

ファイルの監視

gopls に影響を与えるファイルが、関連付けられているエディターの外部で変更されることはごく普通です。

例えば、正しい型チェックを行うために必要なファイルが、git でブランチを切り替えたり、コードジェネレーターによって更新されたりすることで変更されます。

gopls 内でファイルを直接監視することは多くの厄介な問題を抱えていますが、LSP 仕様には、gopls がクライアントにファイルシステムの変更を通知するように要求できるメソッド、特に workspace/didChangeWatchedFiles があります。これは現在、コミュニティメンバーによって gopls に追加されており、#31553 で追跡されています。

このドキュメントのソースファイルは、golang.org/x/tools/gopls/doc の下にあります。

go.dev は、サービスの品質を提供および向上させ、トラフィックを分析するために、Google の Cookie を使用しています。詳細はこちらをご覧ください。