Hi, Pecan, In the latested r84 and with the change to using the std::string output of the both function writeClientLog() and writeServerLog().
I found an interesting thing that I got two different encoding output of the Chinese text in the comments.
One place is here, in the function: bool ProcessLanguageClient::WriteHdr(const std::string &in)
I see that the output of the content(usually the textDocument/didOpen message's content the client try to send to the LSP server) will be in GB2312 in my PC.
While, the content received from the server(usually the textDocument/hover message return from the LSP server) will be in UTF8 format.
I just exam the function body: bool ProcessLanguageClient::WriteHdr(), I see it still use the some kinds of std::string to wxString, and later some wxString to std::string, some conversion will use the default local encoding.
For example:
limitedLogOut = wxString::Format("<<< Write():\n%s", wxString(in)).Mid(0,512) + "<...DATA SNIPED BY LOG WRITE()...>";
The variable in to wxString will use wrong encoding.
So, what I think is that we should use std::string inside the WriteHdr().
Even I see there is a function call:
// Write raw data to clangd server
#if defined(_WIN32)
bool ok = m_pServerProcess->WriteRaw( out ); //windows
if (not ok)
{
writeClientLog("Error: WriteHdr() failed WriteRaw()");
return false;
}
#else
// unix just posts the msg to an output thread queue, so no return code.
m_pServerProcess->Write( fileUtils.ToStdString(out) ); //unix
#endif
I think the content sent to the pipe is still in UTF8 encoding. (I just checked the code in src\winprocess\asyncprocess\winprocess_impl.cpp.
bool WinProcessImpl::Write(const std::string& buff) { return WriteRaw(buff + "\r\n"); }
bool WinProcessImpl::WriteRaw(const wxString& buff) { return WriteRaw(FileUtils::ToStdString(buff)); }
bool WinProcessImpl::WriteRaw(const std::string& buff)
{
// Sanity
if(!IsRedirect()) {
return false;
}
m_writerThread->Write(buff);
return true;
}
