Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.3) Gecko/20090909 SUSE/3.5.3-3.1 Firefox/3.5.3 Build Identifier: Build id: I20090917-0100 Content assist with #include ignores files without a file extension. This is quite annoying since I do a lot of Qt/KDE development and those header files are mostly without a file extension (i.e. #inlude <QString> or #include <KDebug>) It is impossible to create a wildcard string for include files like "Q*" or "K*", since you aren't allowed to create one without a file extension. Searching for files without a file extension would also remove the need to define all the STL headers in General->Content Types-> C++ Headers Reproducible: Always
(In reply to comment #0) The InclusionProposal computer should be changed in order to allow files without extension. The content type for the stl-headers still makes sense because it determines the editor that will be used to present the file.
Hmm, when proposing the files without extension we end up proposing things like 'Makefile', 'Readme' and other useless files. I tend to think that we should leave the implementation as it is.
(In reply to comment #2) > Hmm, when proposing the files without extension we end up proposing things like > 'Makefile', 'Readme' and other useless files. I tend to think that we > should leave the implementation as it is. How about limiting completion to external include files? Files in workspace would only be autocompleted if they have the correct suffix. So any files in /usr/include would be autocompleted since this directory should only contain headers anyway. Another alternative would be to allow patterns like "Q*" or "K*" for header files, forcing a file extension is IMHO stupid anyway. This would stop files like Makefile etc showing up and it would also solve my problem. Problem could be that this would require changes outside of the CDT but I have no idea there.
(In reply to comment #3) > Another alternative would be to allow patterns like "Q*" or "K*" for header > files, forcing a file extension is IMHO stupid anyway. This would stop files > like Makefile etc showing up and it would also solve my problem. > Problem could be that this would require changes outside of the CDT but I have > no idea there. See bug 263316. The proper solution for now is to add all Qt/KDE headers as C++ content type as we do already with the C++ STL headers. We won't include this list in CDT, but could this not be included in the Qt Eclipse integration that Nokia provides? In any case, if you provide a list of relevant file names, I'd be willing to create a plug-in which you can drop in your installation.
(In reply to comment #4) > The proper solution for now is to add all Qt/KDE headers as C++ content type as > we do already with the C++ STL headers. We won't include this list in CDT, but > could this not be included in the Qt Eclipse integration that Nokia provides? > In any case, if you provide a list of relevant file names, I'd be willing to > create a plug-in which you can drop in your installation. I agree this should be part of the Qt integration, as far as I know they wanted to move it to an open development process, like the Qt library, but until then I don't think that will change.
Created attachment 150234 [details] List of Qt headers
Created attachment 150235 [details] List of KDE headers This is not a complete list, but all of those installed on my PC
Created attachment 150487 [details] Bundle to register Qt and KDE headers as "cxxHeader" content-type Drop this jar in the dropins folder of your Eclipse installation.
Thank you very much, works perfectly.
Ok, that's all we can do for now.
Now that there is a Qt integration plugin in CDT, wouldn't it make sense to add that list there? It seems there is no bugzilla category for it, though. Also this workaround is not quite sufficient: every time a new Qt version (or anything else that uses CamelCase headers) is out this plugin has to be updated. Is it not possible to consider files without an extension in the include completion due to underlying eclipse restrictions? I don't mind if file associations don't work (i.e. headers without an extension don't get opened in CDT editor) but it would be EXTREMELY useful to consider them when pressing Ctrl+Space after #include <
I second this, it is REALLY annoying that headers without a file extension are not recognised. I am currently trying to make some patch to the KDE plasmoid, which has includes without extension inside the code. I am getting plenty of parse errors about not found types, which are defined inside the no-ext headers. I obviously can not change oficial version repo to use extensions ;-) . For some reason (time gap since patch till my 3.8 Eclipse version ?) the above mentioned workaround does not work even if the dropped jar appears as Resolved in the Eclipse startup log.
It might seem weird, but IMHO suggesting files like Readme and Makefile is not that bad. The user will start typing some first letters and the list will be considerably filtered. And also, you are already forced to include all directories in your proposal list anyway. A (somewhat) conservative suggestion would be to list ALL files in registered include directories into the proposal list (not only the ones without suffix, but also the ones with ANY suffix). But I'd even suggest including all possible files without considering their extension completely. Because it is legimitate in C/C++, and a user might really want to include "Readme". Another example would be including .xpm files, which is completely reasonable (as they are actually C code defining variable). And personally have included even some .cpp files (I don't remember why, but it can be reasonable when you have a number of functions which might/might not be compiled as inline). If you'd like to help the developer to find its way among (probably) many suggestions, you can add some high level ordering: first, order files with matching case (so, when you start your header file name with "Q", Qt standard header files will appear first while they don't have any extensions; but if you type "q" header files with .h extension will appear first), then the files with recognized header extensions (e.g. .h & .hpp), then the files with no extensions, and finally files with other extensions. Note that it is all about header file completion; so it shouldn't affect how such files are opened in Eclipse (as a side note, eclipse already opens Qt standard header files as C/C++ code when they are opened using F3, which is IMHO great!).
New Gerrit change created: https://git.eclipse.org/r/88920
New Gerrit change created: https://git.eclipse.org/r/88919
Here's what I implemented: - Files that are not known to be C/C++ header files are now considered for inclusion proposals, but ranked below files that are known to be C/C++ header files. - Files that are known to be C/C++ *source* files are still excluded, as are files with names beginning with a '.' (as we almost certainly want to exclude things like .project, .cproject, and similar).
Gerrit change https://git.eclipse.org/r/88919 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=c5f3bbb55afdc169f92d60c4ba828fbff6d77174
Gerrit change https://git.eclipse.org/r/88920 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=3c20d6f0ea67a1fc961a501bbe94229652d43786
Fixed for 9.3.
Mentioned in the 9.3 N&N: https://wiki.eclipse.org/CDT/User/NewIn93#Included_files_with_no_file_extension
