Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Code completion using LSP and clangd
ollydbg:
--- Quote from: Pecan on November 01, 2022, 05:15:21 pm ---...
...
But I'd like to hear how other users feel about it becoming a contrib.
--- End quote ---
+1.
I use clangd_client plugin in my daily work for several months, it works quite well.
It gives more accurate code suggestion, code reference, code-refactoring(rename) feature than the old code completion plugin.
I have maintained the old code completion plugin for many years. The C++ language and its grammar is becoming so complex nowadays, so we need a compiler level parser. Currently only clang based tool has this kinds of feature.
ollydbg:
I see a bug that when the source code has TAB as the indent chars, our C::B editor will report the wrong position to clangd.
It looks like clangd just recognize the TAB as a single char, but in our C::B editor, when we get the column position, a TAB may be recognized as "4 space", in this case, when the clangd_client send the request to the LSP server, it send the wrong column position.
Do you see this bug?
To fix this issue, I think we have to adjust the column position we got from the editor. Any ideas?
EDIT:
The GetColumn() function has such document:
Retrieve the column number of a position, taking tab width into account.
EDIT2
In this page, we can get a "char" based column:
get column number Issue #75 jacobslusser/ScintillaNET
ollydbg:
Other issue is that it looks like the icons are not showing correctly, it looks like the transparent color is shown in black?
See the image shot below:
ollydbg:
--- Quote from: ollydbg on November 05, 2022, 09:14:41 am ---I see a bug that when the source code has TAB as the indent chars, our C::B editor will report the wrong position to clangd.
It looks like clangd just recognize the TAB as a single char, but in our C::B editor, when we get the column position, a TAB may be recognized as "4 space", in this case, when the clangd_client send the request to the LSP server, it send the wrong column position.
Do you see this bug?
To fix this issue, I think we have to adjust the column position we got from the editor. Any ideas?
EDIT:
The GetColumn() function has such document:
Retrieve the column number of a position, taking tab width into account.
EDIT2
In this page, we can get a "char" based column:
get column number Issue #75 jacobslusser/ScintillaNET
--- End quote ---
This issue can be fixed by this patch:
--- Code: ---From 8acd4b5b3bfe74d36583c54c4539dda112c6b1f3 Mon Sep 17 00:00:00 2001
From: asmwarrior <a@b.com>
Date: Sat, 5 Nov 2022 18:09:48 +0800
Subject: handling the char based column, do not take account the TAB width
diff --git a/clangd_client/src/LSPclient/client.cpp b/clangd_client/src/LSPclient/client.cpp
index 1654e1d..424fd0a 100644
--- a/clangd_client/src/LSPclient/client.cpp
+++ b/clangd_client/src/LSPclient/client.cpp
@@ -2301,7 +2301,10 @@ void ProcessLanguageClient::LSP_GoToDefinition(cbEditor* pcbEd, int argCaretPosi
//-const int startPosn = pCtrl->WordStartPosition(edCaretPosn, true);
//-const int endPosn = pCtrl->WordEndPosition(posn, true); //not needed
position.line = edLineNum;
- position.character = edColumn;
+
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = edCaretPosn - linePos;
+ position.character = fauxColumn;
writeClientLog(StdString_Format("<<< GoToDefinition:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
//Tell LSP server if text has changed
@@ -2386,7 +2389,9 @@ void ProcessLanguageClient::LSP_GoToDeclaration(cbEditor* pcbEd, int argCaretPos
DocumentUri docuri = DocumentUri(stdFileURI.c_str());
Position position;
position.line = edLineNum;
- position.character = edColumn;
+
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = edCaretPosn - linePos;
writeClientLog(StdString_Format("<<< GoToDeclaration:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
// Tell server if text has changed
@@ -2476,7 +2481,18 @@ void ProcessLanguageClient::LSP_FindReferences(cbEditor* pEd, int argCaretPositi
//-int startPosn = pCtrl->WordStartPosition(caretPosn, true);
//-const int endPosn = pCtrl->WordEndPosition(posn, true); //not needed
position.line = edLineNum;
- position.character = edColumn;
+
+ // the clangd need char based column, where a TAB equals one char
+ // but GetColumn() function just return the column which retrieves the column number of a position, taking tab width into account.
+ // so we need a hack to get a new fauxColumn
+ // get column number Issue #75 jacobslusser/ScintillaNET - https://github.com/jacobslusser/ScintillaNET/issues/75
+ // var currentPos = scintilla.CurrentPosition;
+ // var currentLine = scintilla.LineFromPosition(currentPos);
+ // var linePos = scintilla.Lines[currentLine].Position;
+ // var fauxColumn = (currentPos - linePos);
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = caretPosn - linePos;
+ position.character = fauxColumn;
writeClientLog(StdString_Format("<<< FindReferences:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
// Report changes to server else reported line references will be wrong.
--- End code ---
I have one question: when I click the context menu->find reference. I see from the client log, there are also "goto declaration" and "goto definition" messages from the json RPC. Do we really need those extra 2 messages? I see find reference messages already correctly return the positions we needed.
Pecan:
--- Quote from: ollydbg on November 05, 2022, 10:44:34 am ---Other issue is that it looks like the icons are not showing correctly, it looks like the transparent color is shown in black?
See the image shot below:
--- End quote ---
How are seeing those icons.
I don't remember displaying them in clangd_client.
Are you sure you're using clangd_client?
I really didn't want to use the icons. But instead use the extra column for useful data.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version