Closed ernesto-glz closed 1 month ago
I believe this is intentional: you cannot include a directory, so at the point where a completion item referring to a directory has been accepted, the #include
statement is still incomplete. You can then invoke completion again to select a file, at which point the closing quote will be inserted.
I believe this is intentional: you cannot include a directory, so at the point where a completion item referring to a directory has been accepted, the
#include
statement is still incomplete. You can then invoke completion again to select a file, at which point the closing quote will be inserted.
This is not the case for the vscode cpp tools extension or the visual studio IDE, you can accept folder suggestions and after that it will suggest the folders and files inside of it, this results in less tedious work to write large include paths.
Also, what's the point of having folders suggestions if you cannot accept it to write less because if you do then the extension will remove the closing quote and would not suggest anything else until you explicitly press ctrl + space.
I hope this explanation will make you understand my point of view because I used the IDE for two years and this is life saver in large projects with tons of folders. Thanks.
So, if I understand correctly, the issue is not really about the closing quote, but rather that after completing the folder, completion is not automatically activated for the files in the folder?
So, if I understand correctly, the issue is not really about the closing quote, but rather that after completing the folder, completion is not automatically activated for the files in the folder?
Nope, the issue is that you cannot chain suggestions because if the first folder suggestion removes the closing quote, the extension will not suggest anything else because again the #include
statement is objectively broken after that.
A good example would be this:
/lib/foo/bar/baz.h
lib
, foo
or bar
because they are folders and because of that the autocomplete is useless until i reach the point where the header file is located an i can accept the suggestion.In VS2022 if you accept /lib
suggestion it will suggest foo
after that and then bar
and then baz.h
.
the issue is that you cannot chain suggestions because if the first folder suggestion removes the closing quote, the extension will not suggest anything else because again the
#include
statement is objectively broken after that
Just to clarify: when you say "the extension will not suggest anything else", you mean it will not automatically suggest the next segment of the path, right? (i.e. it does work if you press the keyboard shortcut to manually trigger suggestions, e.g. Ctrl+Space?)
the issue is that you cannot chain suggestions because if the first folder suggestion removes the closing quote, the extension will not suggest anything else because again the
#include
statement is objectively broken after thatJust to clarify: when you say "the extension will not suggest anything else", you mean it will not automatically suggest the next segment of the path, right? (i.e. it does work if you press the keyboard shortcut to manually trigger suggestions, e.g. Ctrl+Enter?)
Yes Ctrl
+ Space
is my shortcut but imagine doing that for paths that have 5 to 6 nested folders every time just because the extension removes the closing quote.
Here is how VS works:
https://github.com/clangd/vscode-clangd/assets/80600689/1f7eb8a9-0473-4cfe-bc57-136967877e2a
Thank you for the clarification.
So what I was trying to say earlier is that the behaviour you care about is the automatic activation of completion for the next segment.
The absence of the closing quote might be unrelated to the activation behaviour.
The absence of the closing quote might be unrelated to the activation behaviour.
Indeed, as an experiment I prototyped a change that preserves the closing quote. No difference in activation behaviour (you still have to press Ctrl+Space).
The cause of the activation behaviour issue is something else.
The cause of the activation behaviour issue is something else.
It looks like we have an issue on file about this: https://github.com/clangd/clangd/issues/395
I'll close this one as a duplicate.
Duplicate of https://github.com/clangd/clangd/issues/395
When accepting a suggestion in an
#include
statement, if the suggestion contains a trailing/
(indicating a folder), it removes the closing quote ("
) from the#include
statement. However, when accepting suggestions that point to a file, such asbar.h
, it works perfectly.System information clangd version 17.0.1 clangd extension version: 0.1.28 os: windows 11