Open turkeylurkey opened 4 months ago
Interesting, I would like to know if the same behavior is seen in Eclipse. I'm wondering if the problem could be with the data sent from VS Code to LCLS in the second request.
It looks like it works fine on Eclipse with 24.0.3 (actually an internal build of our next release). I deleted my recording but will try to post a new one at some point.
Thanks Scott. So if it works in Eclipse, I think it is unlikely that it is a problem in LCLS. However, the fix may still be in LCLS to accommodate for whatever data is coming from VS Code that leads to the problem. We will have to compare the data that is coming in on the two requests and see what is different. I will mark this as a bug. It will be a low priority though.
This issue came up when working on integrating the latest LSP4IJ for LT IntelliJ. VS Code was tried as a comparison: https://github.com/redhat-developer/lsp4ij/issues/270#issuecomment-2088292926
We use the constructor for CompletionItem
that takes a String
, which is our property key and gets set as the label in CompletionItem
. The suggestion in the referenced issue by Trevor is to use TextEdit
instead of passing the property key as the label. There is a method setTextEdit
on CompletionItem. Will have to investigate using that instead of the label for the key.
When editing bootstrap.properties in some cases completion replaces all of the text I type but in others it leaves some text behind and creates an invalid key. Tested using VS Code and Liberty Tools version v24.0.3.
The correct result: type "com.ibm.ws.log" and select the first result and the key "com.ibm.ws.logging.apps.write.json" is added.
![image](https://github.com/OpenLiberty/liberty-language-server/assets/24705144/25a0d90a-842f-4687-8cdb-3ea17177847f)
Then erase part of the key so that only "com.ibm.ws.log" is showing and select the first result. "com.ibm.ws.com.ibm.ws.logging.apps.write.json" is added.
![image](https://github.com/OpenLiberty/liberty-language-server/assets/24705144/9020de73-a5bb-4b1f-b803-1bcbb6233313)
This seems like a bug.