Hi Guys,<br><br>I thought the suggestion of having separate header file types would be controversial  ;-), otherwise it would have been done by now.<br><br>Let me run through a couple of points about C++ headers and why they need full support as much as possible.<br>


<br>C++ headers are potentially much more complex than C ones with templates and inline functions in them.  So not having language support is significant.  The C++ application I am working on (and which first got me using Geany before I introduced it at work) has only medium complex templates but I still spend as much time getting the .h file to compile as the .cpp file.  And thats without things such as template metaprogramming, which is code written to run at compile time in headers.  As an example, the boost C++ libraries contain lots of complex functionality of which 75% is purely in headers without any supporting body, so lots of work gets done at compile time not at runtime, so its faster, but it makes the headers much more complex.  I think the best example is the sprint library that is a complete parser that does all the stuff bison does at compile time and in the .h files.<br>


<br>The point of all this is that providing support for the C++ .h files is important, so correctly detecting them is important.  So is compiling .h files independently, it is annoying having to pick through errors in the .cpp file (often caused by errors in the .h file) to find the .h errors and fix them first, usually it gets so complex that errors get fixed only a few at a time. It would be much easier to get the .h to compile first.  And on gcc at least, that can leave a pre-compiled header that would speed up further uses of that header.<br>


<br>Now despite all that, I agree with Enrico that the default should be that .h is C, thats the historical use and it fits with Geany development.  <br><br>The marking -*-C++-*- exists on all GNU headers which means it should be present on most Linuxii, I don't know about windows though.  Looking at other (non-system) library headers I've got available, most of the C++ .h files identify themselves and interestingly about 15% of the C .h files identify themselves as C. In terms of the delays in opening the file, it is only intended to look at line 1 which has already been examined for shebang so it is already available in memory, most of the overhead has already occurred.  Having separate C++ header templates with the mark already in it would help users to remember to add it.  BTW it would be good to have these separate .h .hpp templates irrespective of the end result of these discussions because creating headers using C or C++ templates and filenames means you need to delete the main you don't want, add the guards etc.and then change the file extension on save too.<br>


<br>In terms of using make object, the .h doesn't compile to a .o file so thats no good, and I have to admit I don't quite see how make could be arranged to support compilation of .h files for syntax purposes only, without it doing them every build because there is no output file, I suppose separate targets that do not run into the main build could work but I'm not sure how that sits with autotools.<br>

<br>I can understand your concern about flow on effects with other languages, unfortunately I don't know enough of them to contribute to a discussion of if the same problem as .h occurs or if there are other differences between headers and bodies that makes separate filetypes beneficial.<br>

<br>I did a quick survey of how other tools approach this problem (both IDEs and just editors), <br>1. Emacs - templates are manual, uses extension or -*- to separate C & C++<br>2. Anjuta - separate templates for C and C++ headers and body, treats .h as C++ for highlighting, autocomplete doesn't work for keywords<br>

3. gedit - doesn't have templates, .h as C++, no autocompletion<br>4. kate - can't tell because documentation on website didn't work, but see kdevelop<br>5. kdevelop - separate templates for C and C++ headers and bodies, .h highlights as C++, don't know about autocompletion (too many 'not written yet' in the manual and I'm not going to install it just for this)<br>

<br>Not much help really...:-P<br><br>In summary my judgement is that C++ users (me, I'm not claiming to be unbiased) would gain significantly by having proper header file support and C users much less.  And I don't see that either user community loses anything.<br>

<br>The commit of the prototype yesterday was the result of me trying to find out just what is involved, by the time I'd found out, I'd done it (at least I think so). By doing it as a separate commit without any other changes you can look at it and it can be bypassed if I stuffed it up too bad.<br>

<br>I have to continue to propose that this is a worthwhile change, please consider it further.<br><br>Best Regards<br>Lex<br><br>