Giters

niosus / EasyClangComplete

:boom: Robust C/C++ code completion for Sublime Text 3/4

Home Page:https://niosus.github.io/EasyClangComplete/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

include autocomplete enhancement request

matreshkin opened this issue · comments

commented

Regarding #705 (comment)

For my personal case the following behavior would be perfect:

  • the list of folders to search should respect the project structure. All folders that cannot be opened in sublime sidebar, have to be removed from the lookup pathes. I.e. I have -I/repo/root flag for all source files, but my project in sublime constists only of /repo/root/proj1, /repo/root/proj2 folders whereas there are plenty of other subfolders, /repo/root/proj* for example. As a result, headers lookup reach only proj1/includes/inc.h and proj2/includes/inc.h, but never proj3/includes/inc.h despite it exists and actually CAN be included in any code.

  • refreshing the header list could be done on project load/reload and refresh_folder_list window command. New/deleted folders/files would be great triggers, if possible.

  • the behavior can be implemented as a mode of include autocomplete feature.

The main question is - does this functionality fit the plugin, will it be appropriate here? Or maybe it's too specific, or even could be implemented in a separate plugin.

commented

@matreshkin sorry, I didn't really have time to properly look into this.

  • The way I see it, I would ideally like to complete includes for all -I or -isystem flags. The reason being that for a generic project there is no way of knowing where the files will be living. Also, if we constrain the includes completion to project files only, we then exclude all system includes, which is not really what I would like to do.
  • I'm not sure we can load all folders on any form of such refresh as the include folders are defined by the build configuration. Basically, whenever we change a CMakeLists.txt or, more generally, any form of a compilation database, we might change the folders we care about, regardless of the folders present in the project.

I'd still like to have a robust feature like this in the project, but it must be related to the -I flags of a particular translation unit. The way I see it, they can be loaded in a separate thread whenever a new file is opened and stored in its ViewConfig instance. More precisely, it would have to be updated whenever we regenerate a view config if a compilation database entry for this translation unit changes. The big question is what to do with all the folders from all those -I flags. How deep to parse them? When to search the headers? How many to store? The reason the feature is slow for now is that I did not really know how to answer these questions straight away and did not have the time to properly return to thinking about this.