Content assist in LSP gets in the way and doesn't adhere to preferences

[emaayan]

for along time a lot of hidden things were bothering me in eclipse Content assist, that i couldn't put my finger on, but it's so annoying.

the first thing is the auto activation, it jumps up.. on .. every... single ... key stroke, which is insane, and probably takes up resources.
i can't seem to make it stop, now matter what i do, up to a point it jumps up in if statements which is very cumbersome,
i've tried to make the auto activation stop in preferences, but that doesn't seem to work. this behavior doesn't occur in the legacy c editor.

[ghentschke]

Hi, thanks for your feedback!
Have you tried to disable the content assist trigger on every character in the Eclipse preferences?

Which clangd version are you running?

[emaayan]

Hi, thanks for your feedback! Have you tried to disable the content assist trigger on every character in the Eclipse preferences?

Which clangd version are you running?

thanks, that does help , but here's another example , if i do use auto complete for a function call, i still get the auto fill for parameters even though i tried to disable it in the content assist in c/c++

[ghentschke]

if i do use auto complete for a function call, i still get the auto fill for parameters even though i tried to disable it in the content assist in c/c++

I am not sure if I understand you correctly. So you disabled the Enable auto activation on typing as shown in my screenshot above and you still get a completion proposal which you don't want or is the completion proposal content wrong?

[emaayan]

if i do use auto complete for a function call, i still get the auto fill for parameters even though i tried to disable it in the content assist in c/c++

I am not sure if I understand you correctly. So you disabled the Enable auto activation on typing as shown in my screenshot above and you still get a completion proposal which you don't want or is the completion proposal content wrong?

the content is wrong, for example if i type pack.. and do content assist , when i choose packet_capture i expect to be complete packet_capture and not shoved with the entire method signature which just has me do a cleanup afterwords

this looks like the effects of this setting in play even though it's off.

[jonahgraham]

this looks like the effects of this setting in play even though it's off.

:-( I think this is a great highlight of a problem we have as we are transitioning from the traditional C/C++ editor to the LSP based one. There are a bunch of preference pages (and I am pretty sure this one is included) that doesn't apply to Editor (LSP)

[emaayan]

this looks like the effects of this setting in play even though it's off.

:-( I think this is a great highlight of a problem we have as we are transitioning from the traditional C/C++ editor to the LSP based one. There are a bunch of preference pages (and I am pretty sure this one is included) that doesn't apply to Editor (LSP)

this is literally the definition of "re-inventing the wheel" , it's all coming together , it's the same problem i stated with refactoring tools that don't exists in the new editor, but do exists here, and now you have code assistant scattered around or not working, that need to be reimplemented again,
this is basically turning eclispe into vscode because that doesn't have code refactor as well. LSP shouldn't have come to light until a full functionality regression have been mapped out, or at the very least a road map of what features of the legacy CDT would re-implemented and when.

all this, should come up exactly at it is (or as close as possible under Editor (LSP) and in the end, there should be a big button going "migrate preferences from legacy.." copying and converting everything to the new editor.

(and now i've accidentally closed the issse)

[jonahgraham]

this is literally the definition of "re-inventing the wheel" ,

Yes, this is reinventing the wheel. The purpose of CDT LSP is to build on top of the clangd (or potentially other LSP servers) to keep CDT relevant going forward. It is a new tool set that is based on LSP (the same thing as VSCode).

A key problem that CDT LSP is trying to solve is that no one has invested in the CDT parser in the last 5-ish years and the CDT parser does not work well with C++17 and newer language standards.

this is basically turning eclispe into vscode because that doesn't have code refactor as well. LSP shouldn't have come to light until a full functionality regression have been mapped out, or at the very least a road map of what features of the legacy CDT would re-implemented and when.

I am delighted to have the early feedback on your perception of CDT LSP. But, if it isn't suitable for your use case, I would stick to the default flow which is not CDT LSP. At the moment, as a user you need to opt-in to the new CDT LSP flows (by activating the editor as described here). Are you sure you want to be using CDT LSP yet? Are you writing C++17 (or newer) or otherwise writing C/C++ that isn't working will with CDT?

In the meantime, we are accepting contributions, both on improving CDT LSP, and if you want to invest some time and money, on improving CDT's parser.

(and now i've accidentally closed the issse)

I have reopened it.

[emaayan]

this is literally the definition of "re-inventing the wheel" ,

Yes, this is reinventing the wheel. The purpose of CDT LSP is to build on top of the clangd (or potentially other LSP servers) to keep CDT relevant going forward. It is a new tool set that is based on LSP (the same thing as VSCode).

A key problem that CDT LSP is trying to solve is that no one has invested in the CDT parser in the last 5-ish years and the CDT parser does not work well with C++17 and newer language standards.

this is basically turning eclispe into vscode because that doesn't have code refactor as well. LSP shouldn't have come to light until a full functionality regression have been mapped out, or at the very least a road map of what features of the legacy CDT would re-implemented and when.

I am delighted to have the early feedback on your perception of CDT LSP. But, if it isn't suitable for your use case, I would stick to the default flow which is not CDT LSP. At the moment, as a user you need to opt-in to the new CDT LSP flows (by activating the editor as described here). Are you sure you want to be using CDT LSP yet? Are you writing C++17 (or newer) or otherwise writing C/C++ that isn't working will with CDT?

In the meantime, we are accepting contributions, both on improving CDT LSP, and if you want to invest some time and money, on improving CDT's parser.

(and now i've accidentally closed the issse)

I have reopened it.

thanks.
i have no choice in the matter, i'm using espressif ide which has chosen to switch to lsp from their version 3 and many complaints were raised about this, and yes they are working with newer c.
so whatever bugs or issues i open or will open are largely due to using them.
i'm also trying to find a way to integrate github issues into eclipse for the same reason.

[ghentschke]

if i do use auto complete for a function call, i still get the auto fill for parameters even though i tried to disable it in the content assist in c/c++

You can disable the auto fill for parameters with this clangd setting: --function-arg-placeholders=0 in the Eclipse Preference page here:

[emaayan]

if i do use auto complete for a function call, i still get the auto fill for parameters even though i tried to disable it in the content assist in c/c++

You can disable the auto fill for parameters with this clangd setting: --function-arg-placeholders=0 in the Eclipse Preference page here:

thanks, i'm not sure what exactly goes on behind the scenes here, now if only column limit could be controlled the same way.

[ghentschke]

The column limit issue if different because the tool for formatting is clang-format, which will be parametrized by a config file.
The additional argument(s) above is/are clangd command line argument(s) which will be used at startup of the clangd language server.

[emaayan]

this is literally the definition of "re-inventing the wheel" ,

Yes, this is reinventing the wheel. The purpose of CDT LSP is to build on top of the clangd (or potentially other LSP servers) to keep CDT relevant going forward. It is a new tool set that is based on LSP (the same thing as VSCode).

A key problem that CDT LSP is trying to solve is that no one has invested in the CDT parser in the last 5-ish years and the CDT parser does not work well with C++17 and newer language standards.

this is basically turning eclispe into vscode because that doesn't have code refactor as well. LSP shouldn't have come to light until a full functionality regression have been mapped out, or at the very least a road map of what features of the legacy CDT would re-implemented and when.

I am delighted to have the early feedback on your perception of CDT LSP. But, if it isn't suitable for your use case, I would stick to the default flow which is not CDT LSP. At the moment, as a user you need to opt-in to the new CDT LSP flows (by activating the editor as described here). Are you sure you want to be using CDT LSP yet? Are you writing C++17 (or newer) or otherwise writing C/C++ that isn't working will with CDT?

In the meantime, we are accepting contributions, both on improving CDT LSP, and if you want to invest some time and money, on improving CDT's parser.

(and now i've accidentally closed the issse)

I have reopened it.
i have another one for you, i've just installed a brand new pure eclipse and the line length in LSP C editor is actually controlled from the print margin parameter.

[ghentschke]

i have another one for you, i've just installed a brand new pure eclipse and the line length in LSP C editor is actually controlled from the print margin parameter.

I think the print margin has no influence on the line width in the LSP based editor since it can be exceeded.

[emaayan]

this is getting super weird i can't even have it line straight in CLI.

[emaayan]

finally !! this parameter was invalid and i didn't even set it.

[emaayan]

so from my POV there are 2 bugs here, here the first is that i'm not getting feedback from eclispe in the event .clang-format file is invalid, the other bug is probably on espressif for creating a bad default file.

[ghentschke]

finally !! this parameter was invalid and i didn't even set it.

So when you remove the PackContructorInitializers: NextLineOnly line it works? Or is the NextLineOnly argument invalid?

[emaayan]

finally !! this parameter was invalid and i didn't even set it.

So when you remove the PackContructorInitializers: NextLineOnly line it works? Or is the NextLineOnly argument invalid?

i removed the entire line, didn't know what else to put there, so removed it just to be safe.

[emaayan]

if i do use auto complete for a function call, i still get the auto fill for parameters even though i tried to disable it in the content assist in c/c++

You can disable the auto fill for parameters with this clangd setting: --function-arg-placeholders=0 in the Eclipse Preference page here:

btw while this may work initially i've noticed that the setting "vanishes" after a few restarts. it's hard to pin point but i do recall setting , and then after a while it's just gone. but this is just a hack after all.

[ghentschke]

Does only the --function-arg-placeholder setting dissapear ? Or do you have other settings in the Additonal box?
Did you switched workspaces or something?

[emaayan]

Does only the --function-arg-placeholder setting dissapear ? Or do you have other settings in the Additonal box? Did you switched workspaces or something?

no other setting , i may have a previous version of eclispe on the same workspace not sure, but i would expect far more then just that setting to be removed.