-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate autocompletes derived only from the local files of the project? #739
Comments
Hey @alpan If I understood you correctly, you want the plugin to not generate completions based on standard includes? So you would still have a If this is right, then I don't think this actually makes much sense. In the end, the code must be compiled as is, so all the completions will anyway be present in the translation unit object that I get from Does this make sense or did I misunderstand you? |
Thank you for your response. Your understanding is partly correct: I say partly because I see I wasn't entirely clear and should have clarified something. My issue for the most part isn't with member variables/functions, because, as you say, completions for those require object instantiations anyway. So you're right, in that scenario it doesn't make much sense. But consider #include'ing something like intrin.h which has a lot of stand-alone function definitions for x86 intrinsics. Now any time I start coding, my autocompletion is filled by items from that header file. At any given time there is very little chance that I will ever make use of these completions, mostly due to the nature of the work requiring these intrinsics (i.e. very localized and specific optimization work), but also because if I do end up using them, then I will likely go read the actual documentation anyway. So from my perspective, the plugin is doing a lot of work with no discernible benefit 99.9% of the time. On the other hand, I regularly make use of autocompletion for my own structs/classes and function definitions. Not having to jump to function and struct/class definitions to recall how a function is supposed to be called is always valuable. If plugin running speed is not an issue, then a filtering option would pretty much address my concern, of course. That was the kind of thing I looked for in the documentation initially, but couldn't find anything. |
Ok, I see. So just as a quality of life improvement you would like to have a setting that would restrict the autocompletion suggestions to ones from the project folder only, right? |
Yes, that would be fine. |
Ok, I see the point. I'm not sure how relevant this is to the majority of people as it seems to be a bit of a niche feature. I could review a PR for this though if you'd like to contribute. |
hey @niosus after declaring a vector, when I do {
"common_flags" : [
// some example includes
"-I/usr/include",
"-I$project_base_path/src",
// this is needed to include the correct headers for clang
"-I/usr/lib/clang/$clang_version/include",
// For simple projects, you can add a folder where your current file is
"-I$file_path",
],
"lang_flags": {
"C": ["-std=c14"],
"CPP": ["-std=c++14"],
"OBJECTIVE_C": ["-std=c14"],
"OBJECTIVE_CPP": ["-std=c++14"],
},
// A dictionary that defines a mapping from language to an array of valid
// syntaxes for it. The values here are good defaults, but feel free to
// customize the list to your liking. When modifying this setting make sure
// that all 4 languages have values.
"valid_lang_syntaxes": {
"C": ["C", "C Improved", "C99"],
"CPP": ["C++", "C++11"],
"OBJECTIVE_C": ["Objective-C"],
"OBJECTIVE_CPP": ["Objective-C++"]
},
// Ignore triggers and try to complete after each character.
// WARNING: can be very slow
"autocomplete_all" : false,
"errors_style": "phantoms",
"hide_default_completions": true,
"gutter_style": "color",
"linter_mark_style": "squiggly_underline",
"triggers" : [ ".", "->", "::", " ", " ", "(", "[" ],
"progress_style": "Moon",
"show_type_info": false,
"verbose" : true,
"clang_binary" : "clang++",
// Show additional information on hover over function call/variable etc.
// This replaces default sublime on hover behaviour
"show_type_info": true,
// Show body of struct/class/typedef declaration.
"show_type_body" : true,
// We only can get declarations from clang AST. This will show references to
// the symbol under cursor taking them from Sublime Text index.
"show_index_references": true,
// When an includes trigger is typed (" or <) a quick panel will appear that
// will guide the user in picking their includes based on the current
// compilation database' include flags.
"autocomplete_includes": true,
} Is there anything that I am missing? |
@soumya997 is your issue related to this one? It doesn't seem to. Please open a new issue for the new request. |
@niosus ok will do. thanks for mentioning |
System info:
Hi,
I hesitated before opening this issue because it's not an issue, more like an usage/configuration question, and it may be a stupid one. I recently installed ECC and it works well (I only created an empty compile_commands.json file in my project folder and it started working). However for my situation it works a little too well as I only need the autocompletes generated from my own source files, not the various platform/CRT #includes in my project like <intrin.h> or <stddef.h> etc.
Is it possible to configure the plugin such that it generates autocompletes only from the files found in the project's source folder? It's not a dealbreaker by any means, but I imagine this would also make the plugin faster for me, and prevent it from doing work generating autocompletes I will never use.
I did read the entirety of the documentation beforehand, but keep in mind, this plugin is currently working with zero effort on my part. I am not even using CMake, there is literally nothing except a simple batch file I run to compile my code, so I don't actually know how the plugin/clang even figured out how to generate the stuff it generated.
Here are my current plugin settings:
{ "common_flags": [], "show_errors": false, "use_default_includes": false, "use_default_definitions": false, }
Thanks for your time.
The text was updated successfully, but these errors were encountered: