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: http://www.openscenegraph.org/documentation/OpenSceneGraph/include/ 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.
http://www.kdevelop.org/HEAD/doc/api/html/astyle__part_8cpp-source.html 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); if (rw_part) { KTextEditor::EditInterface *iface = dynamic_cast<KTextEditor::EditInterface*>(rw_part); if (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; } } _action->setEnabled(enabled); } 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: BUG: 106379 Option to set the file type to enable the Edit/Format menu. (RMB context menu continues to ignore this setting) Bug: 102705 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.