外掛作者文件

如果您透過編寫編輯器外掛將 gopls 整合到編輯器中，那麼編輯器和 gopls 之間的通訊語義有相當一部分並未在 LSP 規範 中進行說明。

我們在此嘗試記錄這些細節以及對其他外掛作者有幫助的任何其他資訊。

如果您正在自己實現外掛，並且有本頁面未解答的問題，請聯絡我們提問，然後也請將您的發現貢獻回本頁面。

支援的功能

在大多數情況下，您應該檢視 功能索引 來了解 gopls 是否支援某項功能。

要獲得真正權威的答案，您應該檢視 initialize 請求的 結果，其中 gopls 在 ServerCapabilities 中列出了其支援情況。

位置和範圍

許多 LSP 請求會傳遞位置或範圍資訊。這在 LSP 規範 中有描述。

文件中的一個位置（參見下面的 Position 定義）表示為一個基於零的行和字元偏移量。偏移量基於 UTF-16 字串表示。因此，像 a𐐀b 這樣的字串，字元 a 的字元偏移量是 0，字元 𐐀 的字元偏移量是 1，字元 b 的字元偏移量是 3，因為 𐐀 在 UTF-16 中用兩個程式碼單元表示。

這意味著整合者需要計算基於 UTF-16 的列偏移量。請使用 protocol.Mapper 進行所有轉換。

編輯

為了將 gopls 的更改傳達給編輯器，LSP 在響應中支援 TextEdit 陣列，這些 TextEdit 的定義在 TextEdit 中。規範精確說明了如何應用這些 TextEdit。

所有文字編輯的範圍都引用原始文件中的位置。文字編輯的範圍絕不能重疊，這意味著原始文件的任何部分都不能被多個編輯進行修改。但是，多個編輯可以具有相同起始位置：多個插入，或任意數量的插入後跟單個刪除或替換編輯。如果多個插入具有相同的位置，則陣列中的順序定義了插入的字串在結果文字中出現的順序。

所有 []TextEdit 都經過排序，以便反向應用接收到的增量陣列可以實現符合規範的期望結果。

Errors

各種錯誤程式碼在 LSP 規範 中進行了描述。我們仍在確定一個方法返回錯誤意味著什麼；錯誤是否僅用於低階 LSP/傳輸問題，還是其他情況也會導致返回錯誤？有關此問題的討論，請參見 #31526。

目前選擇的方法受到當前流行的編輯器整合中實際處理方式的影響。它很可能會發生變化，並且理想情況下會跨請求變得更加一致。

• textDocument/codeAction：如果計算程式碼操作時發生錯誤，則返回錯誤。
• textDocument/completion：記錄錯誤，返回空結果列表。
• textDocument/definition：如果計算該位置的定義時發生錯誤，則返回錯誤。
• textDocument/typeDefinition：如果計算該位置的型別定義時發生錯誤，則返回錯誤。
• textDocument/formatting：如果格式化檔案時發生錯誤，則返回錯誤。
• textDocument/highlight：記錄錯誤，返回空結果。
• textDocument/hover：返回空結果。
• textDocument/documentLink：記錄錯誤，返回 nil 結果。
• textDocument/publishDiagnostics：如果在計算診斷資訊時發生任何錯誤，請記錄錯誤。
• textDocument/references：記錄錯誤，返回空結果。
• textDocument/rename：如果計算重新命名時發生錯誤，則返回錯誤。
• textDocument/signatureHelp：記錄錯誤，返回 nil 結果。
• textDocument/documentSymbols：如果計算文件符號時發生錯誤，則返回錯誤。

檔案監控

gopls 所依賴的檔案在其關聯的編輯器外被修改是很常見的情況。

例如，進行正確型別檢查所需的檔案會在切換 git 分支時被修改，或者會被程式碼生成器更新。

直接監控 gopls 內部的檔案存在許多棘手的問題，但 LSP 規範 提供了允許 gopls 請求客戶端通知其檔案系統更改的方法，特別是 workspace/didChangeWatchedFiles。目前，社群成員正在 gopls 中新增此功能，該功能已在 #31553 中跟蹤。