Version: CVS (using KDE 3.4.0 Level "b" , SUSE 9.2 UNSUPPORTED)
Compiler: gcc version 3.3.4 (pre 3.3.5 20040809)
OS: Linux (i686) release 2.6.8-24.14-default
This is related to #94710, but it's different enough to justify a new bug report. I'm working with OpenSceneGraph. The toolkit is very nice in many ways. One decision the core developers made which has proven very problematic for me is to use header files without extensions on the filenames. Instead they chose to identify their files using the Emacs style mode specification -*-c++-*- in the first line of the files. Take a look at the includes to see what I mean:
This causes problems with KDevelop in a few ways. PCS cannot be used to build a code completion database. When one of these header files is opened, it is treated like a normal text file. There is no syntax highlighting, and none of the other language support features work. Header files with extensionless file names also cannot be created with KDevelop. That is currently not much of a problem for me because I am not directly adding code to the cvs. But if I were to want to contribute my own code there would be problems using KDevelop to do so.
It's really quite easy to scan a directory for files with the mode specification line.
for f in $(grep -lr '\-*-c++-*-' *);do echo "#include <$f>"; done > all.hpp
will create a file #including all the header files in the include path of the project. Perhaps one approach to some of these issues might be to create a list of files intended to be treated as headers, and pass that list to such tools as PCS.
I really don't like the extensionless headers, but the lead developer on the OSG project certainly believes the problem is with my tools and not his file names.
Just looking at the one part of this problem related to AStyle, I can see
changing this would require a fundamental change in how file types are
currently determined. Or, at least overloading functions throughout
KDevelop. My own inclination is that having every component determine the
type of file it's working with is not an ideal design. It seems preferable
to have one component determine file type, and then pass that information on
to "clients". So, for example, rather than passing the KParts::Part, and
determining it's type by examining the file names directly, there could
either be a globally available function to determine file type called by
functions such as activePartChanged to determine the type of file, or KPart
could have the functionality built in.
void AStylePart::activePartChanged(KParts::Part *part)
bool enabled = false;
KParts::ReadWritePart *rw_part = dynamic_cast<KParts::ReadWritePart*>(part);
KTextEditor::EditInterface *iface =
QString extension = rw_part->url().path();
int pos = extension.findRev('.');
if (pos >= 0)
extension = extension.mid(pos);
if (extension == ".h" || extension == ".c" || extension == ".java"
|| extension == ".cpp" || extension == ".hpp"
|| extension == ".C" || extension == ".H"
|| extension == ".cxx" || extension == ".hxx"
|| extension == ".inl" || extension == ".tlh"
|| extension == ".moc" || extension == ".xpm"
|| extension == ".diff"|| extension == ".patch"
|| extension == ".hh" || extension == ".cc"
|| extension == ".c++" || extension == ".h++")
enabled = true;
In addition to the options of looking at the filename extension, and the mode
specification, it might be reasonable to determine file type by registering a
particular file as source when it appears in a #include of a known source
file. Of course that would require having it in the include path, and having
KDevelop examine the include path.
SVN commit 611652 by webb:
Option to set the file type to enable the Edit/Format menu. (RMB context menu continues to ignore this setting)
Option in formatter settings to format a selection of files.
M +81 -26 astyle_part.cpp
M +3 -1 astyle_part.h
M +79 -1 astyle_widget.cpp
M +1 -0 astyle_widget.h
M +350 -139 astyleconfig.ui
Option in Project/Project Options/Formatting/General/Files TO format
Can set * to allow any file to be formated.