You can use the wildcard expression "*." (star-dot) to find all extensionless files. This is better than * since it excludes *.idl, *.exe, and other extensions you don't want. I believe that this works as a special case on Unix also, though it is slightly different than how the Unix shells would interpret *.
Second, why does having the tag files without the STL headers in it mask the presence of those containers in the auto-tag files from the compiler?
Use Tools > C++ Refactoring > Test Parsing Configuration... to verify that your "active" compiler configuration is what you think it is. Also, if you have an extension specific C++ tag file named "cpp.vtg" (ucpp.vtg on Unix), it will be used ONLY if there is no C++ compiler tag file in play. If you really want "cpp.vtg" to be used, name it something different, "cpp.vtg" is the name generated by the autotag dialog when you tag C++ runtimes, so presumably, if you have a compiler tag file in play, you already have your C++ runtimes covered.
It would be great if someone could give a short explanation of the interworking of
compilers.xml / def_cpp_include_path_re / def_user_langext_files / tagging.
- compilers.xml is just how we store what you set up in Tools > C++ Refactoring > C/C++ Compiler Options... We realized that this duplicated some of the functionality in auto-tag, so we consolidated it around the compiler options, which gives greater flexibility, since you can select a compiler configuration per project, and you can add new compiler configurations, and SlickEdit can automatically detect when these tag files are missing and generate them without needing the autotag dialog at all. compilers.xml has no interaction with the def-vars.
- def_cpp_include_path_re reflects what you configure for "Extensionless C++ File Path Regular Expression:" on Tools > Options > File Extension Setup..., "C", Options... It's a regular expression for directories, used to filtering, not for searching.
- def_user_langext_files reflects what you configure for "Extensionless C++ Files:" on Tools > Options > File Extension Setup..., "C", Options... It has this weird "langext" name for historical reasons. Visual Studio used to ship a file named "langext.dat" which has a list of the extensionless files that they shipped under their "include" directory. Presumably, they used that to set the correct file mode when those files where opened in their editor.
The two configuration options work together in an AND relationship. If you open a file with no extension, we check that it's name matches one of the names in the list of extensionless header files names, and we check if the directory it is in matches the regular expression for directory names. If it matches, then we consider the file as C++. This prevents us from opening an executable that just happens to be named "allocator" as if it were C++. It also prevents us from considering random extensionless files littered in your include directory as C++.
There is no relationship between the configuration options and the compiler configurations. Also, we do not rebuild your tag files if you change the configuration options. The options are aimed at the situation where you open an extensionless file, and we are trying to decide if we show it to you in fundamental mode or C++ mode. However, the options do have the side-effect that when you build you compiler tag files, and we search for "*.", if the options are set right and the file is C++, then we tag it.
I'll be the first to admit that these are a pair of band-aids. In ideal world, we would implement the Unix "file" utility within SlickEdit and use magic numbers and sampling to determine file types. Of course, even if the schedule had room and the developer responsible for that aspect of the product made the changes, we might still need these bandaids on occasion to determine if an extensionless file was C++ or not. The core problem was the gargantuan mistake made by the developers of the ANSI C++ standard when they ruled in favor of extensionless header files.
