Hi,
As a followup to the suggestion below I have committed a prototype of filetypes for C and C++ headers to the build_system branch. The filetype detection also checks .h and no extension files for -*-C++-*- in line one to indicate a C++ header. Just to be annoying the C++ standard headers (as distinct from the C++ versions of the C headers which is what I looked at before) use -*- C++ -*- (extra spaces) and according to the Emacs manual there is much which can go in between the -*- es so I think I might have to look for C++ anywhere between the -*- es. Or fall back to my original idea of C++ anywhere on the line at the risk of comments which just happen to contain C++ triggering the filetype. Admittedly this risk is small as the search is only performed on .h or no extension files. I will think about it some more.
In the meantime since adding filetypes seems to be entwined in lots of areas any suggestions of things I may have missed in terms of adding these filetypes would be appreciated.
Cheers
Lex
2008/11/7 Lex Trotman <elextr@gmail.com>2008/11/7 Nick Treleaven <nick.treleaven@btinternet.com>Yes, I set 2 project build commands, then checked the menu. It doesn't
work after updating the dialog, but reopening the project does work.
interesting, will look at it, I thought I called update_menu everywhere I needed, but must have missed somewhere
Hopefully fixed now
BTW there was a bug where the 3rd project build menu item is created
based on the 2nd label.
Ah yes, the old copy and paste and forget to edit the names trick ;-) will fix
Fixed
In planning my attack on the next phase I have come to the point where I have to to raise something I am sure has been raised before, C & C++ header filetypes.
Currently using C or C++ as the filetype for headers works for highlighting (except for C++ .h files which are taken to be C, so things such as template or namespace are not highlighted).
Then there is a piece of hard code which disables filetype commands for *.h* files. This can become rather messy when new commands are saved by filetype since we can't save any for header files.
I propose that header files become first class citizens and be given their own filetypes with specific highlighting and commands. Detection will be easy for distinct extensions such as .hpp etc but not all compilers seem to properly support them (aside: the C++ standard can be read as only *requiring* support for a single character after the dot though not preventing multi character extensions).
For .h or unnamed files I suggest extending filetypes_detect_from_file_internal() that looks for shebangs to look for "C++" anywhere in line one. This will detect the emacs -*-C++-*- sequence or similar. On my system at least, all the C++ standard header files have this since most do *not* have any extension (eg <iostream>) and many C++ application libraries have them too. So this seems a reasonable approach and will of course assist Geany's replacement of Emacs as "all the worlds programmers favourite editor" ;-)
For default commands for header files I propose just a compile that does a syntax check, since I seem to spend as long getting compile errors out of headers as I do bodies, making them compile before I use them would be helpful. This of course requires different commands for C++ and C so they need to be different filetypes.
Have I missed some key reason for not having distinct C and C++ header filetypes (other than the detection issue)??
In reaching the above understanding I noticed that filetype.c has 'class' in its keywords, this isn't a C keyword.
Cheers
Lex