McPatate
commented
10 months ago I think the fix here should rather be to attempt to set the encoding to utf8 in the initialization call where server and client exchange capabilities. We could issue a warning to the client saying there might be some offsetting errors when utf-16 is the only supported format. It could look something like this:
async fn initialize(&self, params: InitializeParams) -> LspResult<InitializeResult> {
*self.workspace_folders.write().await = params.workspace_folders;
+ let position_encoding = params.capabilities.general.and_then(|general_cap| {
+ general_cap.position_encodings.and_then(|encodings| {
+ if encodings.contains(&PositionEncodingKind::UTF8) {
+ Some(PositionEncodingKind::UTF8)
+ } else {
+ self.client.show_message(MessageType::WARNING, "utf8 is not supported, defaulting to utf16 which may result in offset errors").await;
+ None
+ }
+ })
+ });
Ok(InitializeResult {
server_info: Some(ServerInfo {
name: "llm-ls".to_owned(),
version: Some(VERSION.to_owned()),
}),
capabilities: ServerCapabilities {
text_document_sync: Some(TextDocumentSyncCapability::Kind(
TextDocumentSyncKind::INCREMENTAL,
)),
+ position_encoding,
..Default::default()
},
})
}
rojas-diego
Hi! First of all, thanks a lot for open-sourcing this.
I was working on an internal fork of the project and noticed a potential issue. I have little experience with the LSP and Ropey so this might not be relevant. Anyway, here's the issue:
With the current configuration, Ropey recognises more EOL sequences than the Language Server Protocol. This mismatch can lead to errors when trying to maintain a mirror of the user's documents as the llm-ls' representation might have more lines.
See: https://docs.rs/ropey/1.6.0/ropey/index.html#a-note-about-line-breaks See: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocuments